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Abstract:  Information  needed  to  support  ground  mobility  decision¬ 
making  is  critical  to  the  success  of  ground  operations.  The  ability  to 
rapidly  obtain  and  process  relevant  information  in  a  network-centric 
environment  will  empower  warfare  planners.  In  addition,  future  network¬ 
centric  operations  that  will  include  autonomous  unmanned  ground 
vehicles  as  envisioned  in  the  Future  Combat  Systems  program  will 
increasingly  require  the  exchange  of  well-structured  information  between 
human  forces  and  robotic  systems.  Addressing  this  operational  challenge 
begins  with  a  clear  understanding  of  the  information  content  needed  for 
ground  mobility  planning.  The  purpose  of  the  Mobility  Common 
Operational  Picture  (M-COP)  project  is  to  specify  a  standardized 
vocabulary  and  conceptual  relationships  for  the  expression  and  transfer  of 
ground  vehicle  maneuver  data,  planned  routes,  trafficability  assessments, 
and  other  parameters  associated  with  Future  Force  assured  mobility 
across  Modeling  and  Simulation  (M&S)  systems  and  Battle  Command 
(BC)  systems.  The  scope  of  the  project  was  limited  to  ground  vehicle 
mobility  and  ground  vehicle  maneuver  information.  The  project  identified 
terms  and  concepts  across  relevant  data  representations  that  will  enable 
the  M-COP  capability  to  be  achieved  in  the  current  and  emerging  network¬ 
centric  architecture. 
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1  INTRODUCTION 

In  looking  toward  to  the  future  of  military  operations,  the  U.S.  Army 
Training  and  Doctrine  Command  (TRADOC)  identifies  force  operating 
capabilities  (FOC)  necessary  to  meet  future  demands  across  the  range  of 
military  operations  (HQDA  2005b).  The  FOC-06-01,  Provide  Assured 
Mobility,  serves  as  the  impetus  for  this  research,  specifically  calling  for  the 
establishment  of  the  Mobility  Common  Operational  Picture  (M-COP).  The 
assured  mobility  framework  “includes  all  those  actions  that  guarantee  the 
force  commander  the  ability  to  deploy,  move,  and  maneuver,  by  ground  or 
vertical  means,  where  and  when  desired,  without  interruption  or  delay,  to 
achieve  the  intent”  (HQDA  2005b). 

The  capabilities  resulting  from  this  project  are  intended  to  be  a  standard¬ 
ized  vocabulary  and  formalized  definition  of  the  conceptual  relationships 
that  will  allow  transfer  of  ground  vehicle  maneuver  data,  planned  routes, 
trafficability  assessments,  and  other  parameters  associated  with  assured 
mobility  between  Models  and  Simulations  (M&S)  and  Battle  Command 
(BC)  systems.  It  also  provides  a  preliminary  step  towards  interoperability 
of  future  autonomously  mobile  equipment,  as  envisioned  in  the  suite  of 
Future  Combat  Systems  vehicles,  with  BC  and  other  systems.  The  COP  is 
defined  as  “a  single  identical  display  of  relevant  information  shared  by 
more  than  one  command”  (Joint  Publications  2001).  Moreover,  the  COP  is 
tailorable  and  facilitates  collaborative  planning.  It  thus  “helps  command¬ 
ers  make  timely,  accurate  decisions  about  force  sequence  and  direct 
resources  and  forces  where  needed  by  units  in  theater.”  Elements  of  the 
environment,  friendly  forces,  and  threat  forces  are  included  in  the  COP 
(HQDA  2001a).  These  are  important  considerations  when  determining 
elements  of  the  M-COP.  The  M-COP  is  not  intended  to  be  a  separate  COP 
but  is  composed  of  components  intending  to  convey  data  and  information 
supporting  assured  mobility.  It  should  also  be  pointed  out  that  this  project 
does  not  intend  to  suggest  another  data  model,  although  it  should  serve  as 
a  point  of  reference  for  enhancements  to  existing  data  models.  Addition¬ 
ally,  the  M-COP  is  not  part  of,  or  linked  to,  the  Battle  Management  Lan¬ 
guage  (Blais  et  al.  2005d),  although  again,  this  report  maybe  used  to 
define  future  enhancements  or  extensions  to  it. 
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Several  papers  and  reports  grew  out  of  the  project  execution  and  are 
shown,  along  with  the  project  approach,  flow,  and  products,  in  Figure  l. 
These  earlier  reports  (Richmond  et  al.  2005a;  Blais  et  al.  2005b)  and 
papers  (Blais  et  al.  2005a,  2005c;  Goerger  et  al.  2006)  relating  to  this  pro¬ 
ject  discuss  the  basis  of  the  M-COP  and  the  identification  of  components 
and  attributes  of  a  M-COP  data  representation.  Research  and  development 
continued  on  the  formalization  of  that  representation  in  the  final  stage  of 
the  project  and  are  discussed  in  this  report.  The  first  interim  report 
(Richmond  et  al.  2005a)  contained  a  review  and  analysis  of  doctrine,  data 
structures,  standards,  and  systems  relevant  to  ground  vehicle  maneuver. 
An  initial  slate  of  data  categories  and  features/  attributes  for  the  M-COP 
was  produced  and  presented,  and  a  procedure  for  obtaining  input  from 
stakeholders  was  described.  The  second  interim  report  (Blais  et  al.  2005b) 
described  the  conduct  and  findings  of  the  stakeholders’  analysis.  From  the 
data  collected,  this  report  presented  the  approach  and  design  decisions  in 
creating  a  description  of  the  principal  elements  of  a  M-COP  data  model. 


Blais  et  al.  (2005a) 
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Blais  et  al.  (2005c) 


TASK  2 
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Goerger  et  al.  (2006) 


TASK  3 

Organize  Data,  Information,  and 
Relationships  for 
Data  Model  /  Ontology 


Review  Existing 
Standards 

Design  M-COP 
Common  Data  Model 


Nagle  et  al.(2006) 


TASK  4 

Refine  and  Perform 
Initial  Semantic  Modeling 
for  Mobility/Maneuver  Domain 


Figure  1.  M-COP  model  development  tasks,  products,  and  documentation.  The  tasks  are 
inside  the  four  boxes.  The  products  are  color  coded  to  match  the  tasks. 


A  third  interim  report  (Richmond  et  al.  2006a)  identified  a  number  of 
Global  Information  Grid  (GIG)-based  services  that  will  be  needed  to 
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obtain  the  M-COP  in  the  distributed  information  architecture  of  the 
future.  As  described  in  Richmond  et  al.  (2005a),  the  data  model  will  be 
usable  within  the  context  of  the  GIG  (Joint  Forces  Command  2001).  The 
M-COP  will  be  obtained  through  the  creation  of  virtual  links  between  the 
information  requirements  on  the  user  side  and  information  sources  on  the 
network  side.  The  information  requirements— i.e.,  the  data  and  computa¬ 
tional  products  needed  to  populate  the  user’s  view  of  the  battlespace  situa¬ 
tion  relating  to  mobility— are  derived  from  the  metadata  description  of  the 
M-COP.  In  addition  to  basic  data,  the  M-COP  data  representation  must 
also  support  Community  of  Interest  (COI)  services*  related  to  ground 
vehicle  mobility  and  maneuver. 

This  report  briefly  reviews  the  earlier  project  efforts  (Tasks  1  to  3)  and  pro¬ 
vides  details  on  the  work  done  in  the  final  stage  of  the  effort  (Task  4). 
Required  M-COP  terms  and  concepts  were  identified  and  defined. 
Comparisons  of  the  M-COP  information  requirements  were  made  between 
relevant  data  models,  e.g.,  the  OneSAF  Objective  System  environmental 
data  model  (OOS  EDM),  and  the  Joint  C3  Information  Exchange  Data 
Model  (J3CIEDM).  The  amount  of  information  to  represent  ground  vehi¬ 
cle  mobility  and  maneuver  at  a  high  level  of  fidelity  is  voluminous,  as  will 
be  shown;  however,  by  identifying  these  requirements  across  M&S  and  BC 
domains,  we  have  taken  the  first  step  to  achieve  a  M-COP.  The  report  con¬ 
cludes  with  a  summary  of  lessons  learned  and  recommendations  for  future 
work. 

In  the  following  sections,  the  categories  of  the  M-COP  model  are  described 
by  classes,  subclasses,  and  attributes.  By  “class”  we  mean  a  collection  of 
objects  characterized  by  the  same  set  of  properties.  A  class  can  have  sub¬ 
classes  that  are  more  specific  than  the  class  to  which  they  belong.  The 
properties  of  a  class  are  attributes.  One  instance  of  a  class  is  a  specific 
object  in  the  collection.  In  this  report,  the  following  naming  conventions 
are  used:  classes  and  subclasses  are  in  uppercase  (e.g.,  ROAD),  attributes 
are  in  title  case  (e.g.,  Feature_Type),  and  at  all  levels,  if  the  descriptor  is 
multiple  words,  there  is  an  underscore  between  words  (e.g., 
CLOUD_COVER,  Wind_Speed). 


*  A  service  is  an  abstract  resource  that  represents  a  capability  of  performing  tasks  that  form  a  coherent 
functionality  from  the  point  of  view  of  the  person  or  organization  that  is  providing  the  resource  and  the 
person  or  organization  that  wishes  to  use  the  resource.  The  service  is  often  a  Web  service.  Source: 
http://www.w3.Org/TR/ws-gloss/#service. 
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2  NOTIONAL  USE  CASE 

A  notional  use  case  designed  to  demonstrate  the  M-COP  context  and  util¬ 
ity  was  developed  and  presented  in  Burk  et  al.  (2007)  and  is  given  below. 

The  mission  is  a  tactical  scout  reconnaissance  mission  at  the  platoon  level 

lLT  Griffin  receives  a  mission  from  his  higher  head¬ 
quarters  (HQ)  to  conduct  a  route  reconnaissance  to 
facilitate  the  movement  of  humanitarian  relief  and 
unit  logistic  convoys  in  support  of  the  unit’s  expand¬ 
ing  operations  into  the  fringes  of  a  troubled  region. 

The  route  will  be  used  to  support  the  movement  of 
medical,  food,  and  fuel  supplies,  as  well  as  engineer¬ 
ing  equipment  to  facilitate  the  reconstruction  of  the 
road  infrastructure  and  hospital  facilities  within  the 
expanded  area  of  operations.  Knowing  that  there  are 
several  things  he  must  consider  in  both  planning  his 
mission  and  conducting  the  reconnaissance  to  provide 
HQ  with  the  necessary  intelligence  it  needs  to  perform 
successful  convoy  operations  along  the  intended 
route,  lLT  Griffin  starts  to  develop  his  reconnaissance 
plan  to  ensure  he  collects  all  relevant  information.  He 
receives  a  listing  of  check  points  (CPs)  and  10  areas  of 
interest  from  the  unit’s  S2,  intelligence  officer,  which 
he  is  specifically  told  to  investigate  for  possible 
impediments  to  convoy  movement. 

lLT  Griffin’s  platoon  departs  on  time  from  Start  Point 
(SP)  Green.  It  moves  in  a  V  formation  with  two  sec¬ 
tions  overwatching  the  route  from  key  terrain  along 
the  route,  while  the  headquarters  section  traverses  the 
route  collecting  relevant  data.  Throughout  the  mis¬ 
sion,  the  teams  note  any  terrain  that  would  be 
adversely  affected  by  inclement  weather,  such  as 
heavy  rainfall. 

Shortly  after  crossing  the  Line  of  Departure  (LD), 

Team  C  notes  3  o-ft  poles  with  wire  (probably  electri- 
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cal  lines)  on  both  sides  of  the  road,  with  wires 
occasionally  drooping  across  the  road.  Owing  to  lim¬ 
ited  maintenance  in  this  sector,  they  are  not  continu¬ 
ous.  Some  wires  appear  to  be  professionally  installed 
while  others  look  as  if  they  are  installed  by  some  of 
the  local  inhabitants.  The  C  Team  Leader  notes  the 
location  of  these  poles  and  wires,  as  they  may  come  in 
contact  with  convoy  vehicle  antennae. 

As  the  platoon  passes  CP  5,  Team  A  observes  a  vehicle 
on  the  side  of  the  road.  The  A  Team  Leader  notifies 
Teams  B  and  C  of  the  vehicle’s  location  so  they  are 
prepared  to  deal  with  it  as  they  traverse  the  route.  Ini¬ 
tially  they  can  only  identify  the  object  as  a  vehicle. 
Further  investigation  shows  it  is  sitting  completely  off 
the  road  and  unoccupied.  Sensing  a  potential  impro¬ 
vised  explosive  device  (IED),  lLT  Griffin  notifies 
higher  HQ  and  is  told  to  bypass  the  vehicle  and  con¬ 
tinue  with  the  mission. 

The  route  crosses  a  river  at  CP  6.  The  teams  provide 
overwatch  for  each  other  as  they  cross  the  bridge. 
They  note  the  load  capacity  and  general  condition  of 
the  bridge.  This  includes  any  potential  sabotage  or 
natural  degradation  from  exposure  to  vehicle  traffic 
and  weather.  Also,  the  potential  for  the  bridge  to 
become  washed  out  during  heavy  rains  or  increased 
flow  from  upstream  conditions  is  noted.  The  teams 
complete  their  assessment  by  making  a  careful  check 
of  potential  fording  sites  in  the  area  in  the  event  the 
bridge  is  not  available. 

At  CP  7,  the  platoon  encounters  a  highway  overpass. 
The  teams  check  its  height  and  condition.  Addition¬ 
ally,  Teams  A  and  B  scout  alternative  routes  for  over¬ 
sized  vehicles  that  may  not  make  it  under  the  over¬ 
pass. 

The  majority  of  the  road  is  concrete,  but  sections  are 
worn  away  and  consist  of  gravel  or  packed  dirt.  Team 
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C  notes  the  location  of  extremely  rough  sections  and 
road  side  areas  that  could  be  used  for  refueling  or 
unscheduled  maintenance  needs.  They  also  note 
choke  points  along  the  route.  These  include  areas  that 
are  possibly  too  narrow  for  larger  vehicles  to  pass, 
such  as  Heavy  Equipment  Transports  or  armored 
vehicles.  They  check  the  shoulder  of  the  road  for  ease 
of  entry  or  exit  from  the  road  network.  The  team  also 
notes  steep  drop-offs  or  extremely  rough  surfaces  that 
can  impede  rapid  transition  to  off-road  travel. 

They  also  identify  key  terrain  along  the  route,  such  as 
high  ground  surrounding  the  route  where  enemy  or 
friendly  forces  could  launch  an  attack  or  simply 
observe  movement  along  the  route.  Conversely,  they 
assess  the  fields  of  fire  available  to  friendly  troops  that 
use  the  route  as  well  as  cover  and  concealment. 

Prior  to  CP  8,  a  road  intersection,  the  platoon  comes 
upon  a  second  smaller  road  intersection.  lLT  Griffin 
believes  this  could  be  confusing  to  a  convoy  com¬ 
mander,  especially  at  night,  causing  the  convoy  to 
turn  too  soon  down  the  wrong  road.  He  makes  careful 
note  to  mark  this  location  as  a  potential  navigation 
challenge.  He  also  sends  the  updated  map  informa¬ 
tion  through  the  appropriate  intelligence  channels  to 
have  the  new  road  added  to  overlays  and  future  maps. 

Near  the  end  of  the  route,  the  road  takes  the  platoon 
around  a  small  village.  Like  the  river  crossing,  the 
teams  provide  overwatch  for  each  other  as  they  pass 
the  village.  They  note  that  there  is  some  kind  of  festi¬ 
val  going  on  in  the  center  of  town.  Suddenly,  they  hear 
the  distinct  sound  of  AK-47  fire  and  immediately  train 
their  weapons  in  the  direction  of  the  sound.  They 
watch  carefully  and  realize  that  the  celebration  is  a 
wedding  party  and  the  gunshots  are  simply  shots  in 
the  air,  common  in  this  culture.  They  note  the  inci¬ 
dent  for  future  reference. 
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Throughout  the  mission,  the  scout  teams  communi¬ 
cate  with  one  another  using  tactical  radio  systems. 

They  also  maintain  communication  with  their  higher 
headquarters.  Prior  to  departing,  the  unit  signal  offi¬ 
cer  advised  them  of  potential  “dead  spots”  for  fre¬ 
quency  modulation  (FM)  communications.  They  per¬ 
form  radio  checks  in  these  locations  while  conducting 
the  reconnaissance  to  ensure  that  convoys  will  be  able 
to  maintain  communications  while  on  the  route.  If 
unable  to  maintain  communications  in  these  masked 
areas,  the  platoon  must  identify  locations  for  retrans¬ 
mission  stations  to  cover  these  dead  spots. 

Upon  completing  the  route,  the  teams  return  to  their 
home  base  along  the  route.  This  trip  is  faster  as  they 
were  already  somewhat  familiar  with  the  route,  but 
they  did  notice  a  culvert  that  ran  under  the  road  just 
outside  the  village  that  they  had  overlooked  when  the 
gunshots  went  off.  They  dismounted  scouts  to  take  a 
careful  look  at  the  entrances  to  the  culvert  as  a  possi¬ 
ble  place  to  hide  explosives  or  launch  enemy  attacks 
upon  the  convoys.  The  scouts  also  identify  if  the  cul¬ 
vert  load  classification  would  be  able  to  handle  an 
increased  load  from  convoy  traffic. 

When  the  platoon  returned  to  its  home  base,  it  con¬ 
ducted  a  thorough  debriefing  with  the  squadron  S2 
(intelligence),  S3  (operations),  and  S4  (logistics)  offi¬ 
cers.  They  relayed  all  that  they  had  observed  during 
the  mission. 

Although  this  reconnaissance  was  explained  as  an  actual  mission,  it  could 
just  as  easily  have  been  part  of  a  simulation  training  mission.  For  instance, 
a  unit  preparing  to  deploy  may  want  to  have  its  cavalry  squadron  rehearse 
route  reconnaissance  missions  in  a  realistic  training  environment.  This 
can  readily  be  coded  into  a  three-dimensional  driving  simulator  that  per¬ 
mits  the  platoon  leader  to  “drive”  the  route  while  transmitting  information 
to  a  squadron  HQ  for  it  to  begin  its  analysis  of  the  data  before  sending 
them  to  a  higher  HQ.  This  would  permit  multiple  echelons  to  train  in  as 
realistic  a  scenario  as  possible.  The  information  required  for  the  real-world 
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mission  would  match  that  of  the  simulation  mission.  The  M-COP  will 
enable  seamless  transfer  of  the  information  between  the  real  world  and  the 
simulation  by  standardizing  the  data  model  with  terminology  relevant  to 
ground  mobility  and  maneuver. 

A  well-defined  data  model  and  formalized  ontology  provide  the  means  to 
share  data  and  information  gathered  during  the  reconnaissance  mission, 
as  well  as  all  the  necessary  mobility  information  that  the  scout  platoon 
would  require  to  perform  that  mission.  An  ontology  is  a  “formal  specifica¬ 
tion  of  a  conceptualization”  (Gruber  1993),  a  well-defined  vocabulary  iden¬ 
tifying  the  concepts  in  a  domain  of  interest,  including  description  of  the 
relationships  among  the  concepts.  From  the  tactical  scout  reconnaissance 
mission  above,  the  example  of  the  vehicle  on  the  side  of  the  road  provides 
several  insights.  The  first  is  that  a  vehicle  can  be  classified  as  a  mode  of 
transportation  as  well  as  an  obstacle  or  even  a  weapon.  In  Somalia,  junked 
cars  were  pushed  into  intersections  and  lit  on  fire  to  act  as  barricades. 

They  are  currently  employed  in  Iraq  as  IEDs:  remotely  detonated  or  deto¬ 
nated  by  a  suicide  bomber.  These  “new”  uses  of  the  vehicle  necessitate  a 
method  of  describing  one  in  general  terms  (two-wheeled,  four-wheel, 
tracked,  etc.)  as  well  as  specific  purpose  (obstacle,  mode  of  transportation, 
etc.)  so  that  all  parties  receiving  information  about  the  vehicle  conceptual¬ 
ize  the  same  thing.  The  M-COP  ontology  captures  our  understanding  of 
this  non-standard  but  important  use  of  the  vehicle  by  describing  a  class  of 
obstacles,  where  by  “class”  we  mean  a  collection  of  objects  characterized 
by  the  same  set  of  attributes  or  properties.  One  instance  of  that  class  (that 
is,  a  specific  object  in  the  collection)  may  be  a  truck  that  has  been  disabled 
or  abandoned  and  currently  is  being  used  to  block  or  slow  traffic  on  a 
route.  If  it  is  a  friendly  vehicle  that  simply  needs  maintenance  assistance, 
then  it  will  also  eventually  become  a  mode  of  transportation— i.e.,  it  may 
be  said  to  belong  to  the  transportation  vehicle  class.  This  requires  the 
instance  to  have  multiple  parent  classes.  Standard  taxonomic  hierarchies 
cannot  capture  this  sort  of  relationship,  but  ontologies  defined  using  one 
of  the  DOD-supported  definition  languages  such  as  Web  Ontology  Lan¬ 
guage*  (OWL)  can.  Additionally,  as  new  uses  for  the  vehicle  are  identified, 
the  ontology  can  be  updated  and  modified  to  address  all  the  new  attributes 
and  functions  of  the  new  vehicle  type  (Goerger  et  al.  2006). 


*  http://www.w3.org/TR/owl-features/ 
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3  TASK  1:  SYSTEM  DATA  AND  ALGORITHM 
RESEARCH 

Task  l  presented  an  analysis  of  systems,  data  structures,  format,  and  Army 
doctrine  in  the  context  of  ground  vehicle  mobility  and  the  COP  (Richmond 
et  al.  2005a;  Blais  et  al.  2005a).  An  initial  slate  of  categories  and  features/ 
attributes  for  the  M-COP  was  produced  in  a  tabular  format  and  a  proce¬ 
dure  developed  for  obtaining  input  and  consensus  from  stakeholders. 
Emerging  concepts  and  capabilities  of  the  GIG,  current  and  emerging 
standards,  and  tools  were  investigated  and  were  used  in  follow-on  work. 
When  fully  defined,  numerous  venues  exist  for  posting  and  registering  the 
M-COP  ontology,  and  other  products— such  as  the  Department  of  Defense 
(DOD)  Extensible  Markup  Language  (XML)  repository,  Army  Battlespace 
Environment  (ABE)  registry,  and  Command  and  Control  Information 
Exchange  Data  Model  (C2IEDM)  enhancements— that  will  result  from  this 
work.  The  M-COP  team  developed  this  definition  for  the  M-COP  based  on 
various  authoritative  definitions  for  the  COP,  including  JP  3-0,  Doctrine 
for  Joint  Operations,  and  Army  FM  3-0,  Operations: 

Mobility  Common  Operational  Picture  (M-COP):  A 
subset  of  the  COP  consisting  of  relevant  movement  and 
maneuver  data  and  information  shared  by  more  than 
one  command.  The  M-COP  can  be  tailored  for  various 
users  and  will  include  data  and  information  for  mobil¬ 
ity  of  individual  combatants,  ground  vehicles,  and 
autonomous/robotic  vehicles.  —  M-COP  Team 

As  a  review,  the  principal  published  documents  used  are  listed  below; 
Richmond  et  al.  (2005a)  should  be  consulted  for  specific  information 
extracted  from  them. 

Doctrine 

•  Army  Force  Operating  Capabilities  and  Field  Manuals. 

•  Joint  Publications. 

•  Army  Operations  Order  format  and  Intelligence  Preparation  of  the 
Battlefield  (IPB)  process. 

•  Army  Universal  Task  List  (AUTL). 
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Data  Structures  and  Specifications 

•  Environmental  Data  Coding  Specification  (EDCS). 

•  Military  Scenario  Development  Language  (MSDL). 

•  Battle  Management  Language  (BML)  and  Command  and  Control 
Information  Exchange  Data  Model  (C2IEDM). 

•  DOD  Discovery  Metadata  Specification  (DDMS). 

•  Geospatial  Standards,  Specifications,  and  Data  Dictionaries. 

Existing  Systems 

•  Army  Battle  Command  System  (ABCS). 

•  Force  XXI  Battle  Command  Brigade  and  Below  (FBCB2)  and  Blue 
Force  Tracker  (BFT). 

•  Commercial  Joint  Map  and  Tool  Kit  (C/JMTK)  with  Battlespace 
Terrain  Reasoning  and  Analysis  (BTRA). 

Emerging  Systems 

Global  Information  Grid  (GIG). 
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4  TASK  2:  INITIAL  M-COP  REQUIREMENTS 


Task  2  consisted  of  a  stakeholders’  analysis  to  describe  the  top-level  design 
of  a  common  data  model  for  the  M-COP.  The  stakeholders’  analysis  proved 
to  be  a  valuable  method  for  prompting  and  collecting  expert  input  for 
identifying  theM-COP  information  requirements.  The  inputs  provided  an 
excellent  foundation  for  identifying  top-level  data  categories  for  designing 
the  M-COP  data  model.  Some  key  components  of  Task  2  work  activities 
are  described  below.  More  thorough  treatment  of  this  task  and  related 
findings  can  be  found  in  Blais  et  al.  (2005b)  and  Goerger  et  al.  (2006). 

While  an  initial  slate  of  potential  M-COP  elements  was  derived  in  Task  1, 
based  on  review  of  doctrine  and  authoritative  sources,  Task  2  involved 
identifying,  expanding,  and  refining  the  M-COP  information  requirements 
by  eliciting  input  from  the  broader  community  of  stakeholders  in  the  use 
of  the  M-COP,  and  synthesizing  this  with  data  and  information  identified 
from  doctrinal  sources  in  preceding  work.  The  M-COP  team  identified 
stakeholders  in  the  area  of  BC  and  M&S  interoperability  and  assured 
mobility,  and  conducted  several  collaborative  sessions  to  obtain  their  per¬ 
spectives  on  M-COP  requirements.  Furthermore,  stakeholders  included, 
but  were  not  limited  to,  active  duty  military  representatives  at  the  United 
States  Military  Academy  (USMA)  with  current— e.g.,  Operation  Iraqi  Free¬ 
dom  (OIF)  and  Operation  Enduring  Freedom  (OEF)— experience  as  well  as 
those  with  earlier  battle  command,  training,  and  doctrinal  experience. 

The  problem  definition  phase  of  the  Systems  Engineering  Management 
Process  (SEMP),  a  robust,  deliberate  problem-solving  methodology  taught 
in  the  Department  of  Systems  Engineering  at  the  USMA,  was  applied  for 
this  task.  The  results  of  the  problem  definition  phase  were  system  defini¬ 
tion,  corresponding  functional  decomposition,  and  identification  of  M- 
COP  required  information  elements  and  hierarchical  relationships.  The 
system  under  consideration  was  the  battlefield  operating  system  (BOS),  or 
system  of  systems.  The  functions  and  subfunctions  that  the  system  must 
perform  were  scoped  using  the  Army  Universal  Task  List  (AUTL)  (HQDA 
2003b)  as  the  framework  with  which  to  map  and  augment  information 
derived  from  the  stakeholders’  analysis  and  Task  1  research. 


12 


ERDC  TR-07-4 


The  brainstorming  exercises  were  structured  around  a  focus  question: 
“What  does  the  commander  need  to  know  to  maneuver  in  the  battle- 
space?”  In  addition,  participants  in  different  sessions  were  asked  to  brain¬ 
storm  groupings  for  M-COP  elements  or  comment  on  proposed  groupings. 
There  was  no  clear  single  theme  that  emerged  for  the  groupings,  instead 
there  were  several  different  ideas  proposed  to  include  the  use  of  the  BOS. 


Table  1.  M-COP  top-level  categories. 


Categories  from  Functional 
Decomposition 

Definitions 

Terrain 

Natural  and  manmade  features  and  their  attributes  that  may  influence 
mobility  or  maneuver  of  ground  vehicles. 

Obstacles 

Terrain  features  or  other  objects  or  conditions  that  disrupt  or  impede 
movement  of  ground  vehicles. 

Weather 

Observed  and  forecasted  weather  conditions  that  affect  mobility  and 
maneuver. 

Maneuver  Analysis 

Results  of  analysis  related  to  ground  vehicle  movement  relative  to  mission, 
command  and  control,  local  culture,  and  other  considerations. 

Route  Finding 

Results  of  and  related  information  for  finding  a  minimum-cost  route  in  a 
maneuver  search  space. 

Threat  Analysis 

Locations,  capabilities,  and  other  information  (potential  actions)  relating  to 
things  that  can  threaten  a  mission.  Note  that  this  can  include,  in  addition  to 
enemy  forces,  local  population,  and  cultural  effects  as  they  affect  friendly 
maneuver  (Melby  and  Glenn  2002). 

Forces 

Information  relating  to  maneuver  and  transportation  units  and  individual 
platform  locations  and  capabilities  as  related  to  mobility  and  maneuver. 

Utilities 

Metadata  that  may  be  applicable  to  all  elements  of  the  M-COP. 

In  Task  2,  the  principal  categories  of  information  requirements  of  the  M- 
COP  were  ultimately  categorized  as  described  in  Table  1  and  include 
elements  of  threat  forces,  friendly  forces,  and  environment  as  indicated  in 
FM  3-0  (HQDA  2001a).  It  is  important  to  note,  however,  that  the  team 
recognizes  there  is  no  one  definitive  “answer”  for  the  list  of  M-COP  ele¬ 
ments  or  their  categorization.  The  goal  is  not  to  provide  a  “perfect”  data 
model  but  to  provide  an  actionable  model  that  captures  the  majority  of  the 
identified  ground  vehicle  mobility  information  requirements.  It  should 
also  provide  a  solid  basis  for  evolution  of  the  data  model  over  time  as 
battlespace  conditions  and  situations  change  and  as  autonomously  mobile 
ground  equipment  and  other  intelligent  systems  are  refined  and  integrated 
over  time  into  battlespace  forces. 


In  addition  to  spatial  characteristics,  objects  described  within  the  M-COP 
can  have  temporal  properties,  such  as  an  obscurant  or  contaminated  area 
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that  disperses  over  time,  or  a  physical  feature,  such  as  a  river  bed,  that  can 
be  dry  or  flooded  under  certain  conditions  at  different  times  of  the  year.  In 
fact,  all  the  principal  components  of  the  M-COP  data  model  can  be  consid¬ 
ered  to  have  temporal  characteristics,  for  example: 

•  Terrain :  The  surface  condition  of  a  road  will  change  based  on  tempera¬ 
ture  and  precipitation  (dry  to  wet,  snow  or  ice  cover)  affecting  vehicle 
speeds. 

•  Obstacles:  A  minefield  may  be  an  obstacle  at  one  point  in  time  but  no 
longer  be  an  obstacle  when  a  clearly  marked  lane  has  been  made 
through  it. 

•  Weather:  Planning  needs  to  be  concerned  with  current  and  near-term 
weather  conditions,  as  well  as  forecasted  conditions  at  some  future 
period  of  time  in  some  particular  geospatial  region. 

•  Maneuver  Analysis:  Conditions  considered  in  maneuver  analysis  for  a 
mission  in  24  hours  can  be  considerably  different  from  that  for  a 
mission  in  72  hours. 

•  Route  Finding:  Routes  planned  under  current  conditions  can  be 
considerably  different  from  routes  planned  under  forecasted 
conditions. 

•  Threat  Analysis:  Threat  conditions  change  over  time  as  the  enemy 
maneuvers,  or  as  attrition  or  reinforcement  occurs.  Threat  analysis  has 
to  deal  with  current  perception  as  well  as  projected  threat  disposition. 

•  Forces:  The  ground  vehicle  mobility  capabilities  of  the  forces  change  as 
vehicles  suffer  battle  and  non-battle  losses  and  as  fuel  supplies  are 
expended.  The  future  composition  of  a  force  can  depend  on  forecasted 
threat  and  weather. 

From  this  perspective,  temporal  considerations  may  be  best  applied  in  the 
Utilities  component  to  apply  to  all  the  other  components. 

From  a  cardinality  perspective,  the  M-COP  data  model  needs  to  contain 
one  or  more  geographical  region  providing  the  terrain  data,  and  these 
regions  may  overlap  or  be  distinct,  and  may  or  may  not  be  adjacent 
regions  in  three-dimensional  space. 

This  task  also  included  evaluating  data  modeling  techniques  that  provided 
insights  into  ontology  development  to  guide  model  refinement  in  subse¬ 
quent  phases  of  the  project.  In  addition,  the  evaluation  indicated  the  soft¬ 
ware  services  that  will  be  needed  to  support  the  M-COP  generation  in  the 
future  GIG  environment.  Figure  2  is  a  popular  depiction  of  the  spectrum  of 
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Figure  2.  View  of  data/knowledge  representations  (Obrst  and  Davis  2006).  UML  is  Unified  Modeling 
Language,  RDF/S  is  Research  Description  Framework/Schema,  DB  is  database,  OWL  is  Web  Ontology 
Language,  and  XML  is  Extensible  Markup  Language. 


data/knowledge  representations  used  to  help  convey  the  idea  of  formal¬ 
ized  semantics  in  data  modeling.  Long-established  data  modeling  tech¬ 
niques  are  indicated  at  the  lower  left  in  the  diagram,  including  the  tech¬ 
niques  of  relational  data  base  schema  and  entity-relationship  (ER)  dia¬ 
grams.*  Parallel  data  structuring  techniques  have  emerged  from  the  World 
Wide  Web  community  involving  the  use  of  XML  and  XML  schema.  These 
techniques  establish  strong  syntactic  structures  for  exchange  and  process¬ 
ing  of  data,  but  lack  the  semantic  content,  readily  understood  by  humans, 
needed  to  achieve  greater  autonomy  in  software  processing.  The  current 
state  of  practice  is  largely  entrenched  in  the  lower  left  half  of  the  spectrum. 
In  recent  years,  many  authors  in  the  DOD  BC  and  M&S  communities  have 
made  strong  arguments  for  the  necessity  of  moving  further  up  the  spec¬ 
trum  to  have  any  hope  of  achieving  more  effective  interoperability  across 
systems  (Tolk  and  Muguira  2003).  The  World  Wide  Web  Consortium  and 
extremely  active  computer  science  and  information  technology  research 
communities  are  creating  new  standards  and  tools  to  enable  the  expres- 


*  An  entity  in  the  context  of  a  relationship  diagram  is  anything  about  which  data  need  to  be  stored. 
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sion  of  stronger  semantic  content  in  data  models.  The  overarching  initia¬ 
tive  driving  these  developments  is  the  Semantic  Web: 

“The  Semantic  Web  is  specifically  a  web  of  machine- 
readable  information  whose  meaning  is  well-defined 
by  standards:  it  absolutely  needs  the  interoperable 
infrastructure  that  only  global  standard  protocols  can 
provide.”  (Tim  Berners-Lee,  in  Fensel  et  al.  2003.) 

A  major  part  of  the  foundation  for  the  Semantic  Web  is  the  syntactic 
strength  of  XML,  together  with  its  flexibility  to  allow  definition  of  new  lan¬ 
guages.  The  Semantic  Web  comprises  layers  of  metadata  for  describing 
data  in  terms  of  concepts  and  interrelationships  among  concepts.  Current 
and  emerging  Semantic  Web  standards— Research  Description  Framework 
(RDF),  RDF/Scheme  (RDF/S),  Web  Ontology  Language  (OWL),  Semantic 
Web  Rule  Language,  and  others— enable  developers  to  move  up  the  spec¬ 
trum  from  conceptual  modeling  to  logical  theory. 

The  M-COP  project  activities  were  conducted  to  achieve  as  high  a  level  of 
representation  of  various  components  of  the  model  as  possible.  Unfortu¬ 
nately,  in  the  early  stages  of  the  project,  it  became  apparent  that  much  of 
the  data  needed  to  create  the  M-COP  were  not  available  at  consistent 
levels  of  specification,  resulting  in  more  extensive  effort  to  identify  and 
define  M-COP  information  components  than  originally  expected.  Still,  we 
find  that  the  work  done  on  the  M-COP  project  represents  one  of  the  few 
concerted  efforts  to  establish  a  comprehensive  data  set  supporting  a 
specific  command  need— that  of  performing  ground  movement  planning. 
The  identification  of  top-level  data  categories  in  Task  2  helped  to  create 
better  context  for  more  detailed  data  modeling  activities  in  Task  4. 


16 


ERDC  TR-07-4 


5  TASK  3:  DEVELOPMENT  OF  BASE 

CAPABILITIES  IN  DATA  MAPPINGS  AND 
PROCESSING  SERVICES 

Services  related  to  the  M-COP  were  identified  from  three  perspectives: 

•  GIG  Core  Enterprise  Services  needed  to  support  the  M-COP. 

•  M-COP  services  that  can  be  provided  to  other  domains  (each 
represented  by  a  COI)  on  the  GIG. 

•  Services  provided  by  other  domains  that  are  needed  to  support  the  M- 
COP. 

GIG  Core  Enterprise  Services  Supporting  the  M-COP 

Services  to  be  provided  by  the  GIG  Core  Enterprise  Services  (CES)  include 
(JROC  2005): 

•  Enterprise  Service  Management:  “the  ability  to  monitor,  manage,  and 
scale  web  services  within  a  Service-Oriented  Architecture  (SOA) 
Foundation  to  ensure  the  service  offerings  are  available  to  the  DOD 
enterprise.”  As  an  activity  expecting  to  contribute  to  the  evolution  of 
the  GIG,  the  M-COP  must  employ  GIG  CES  Enterprise  Service 
Management  to  become  registered  and  thereby  become  available  to  the 
enterprise  through  the  Core  and  Environment  Control  Services  (ECS). 

•  Machine- to -Machine  (M2M)  Messaging:  “services  to  support  synchro¬ 
nous  and  asynchronous  information  exchange.”  The  M-COP  will  make 
use  of  GIG  M2M  messaging  services  for  interactions  with  other 
systems  and  processes  on  the  GIG.  When  provided  as  a  Web  service  in 
the  GIG  environment,  such  messaging  is  likely  to  take  the  form  of 
Simple  Object  Access  Protocol  (SOAP)  messages  over  Hyper  Text 
Transfer  Protocol  (HTTP),  but  other  protocols  may  be  employed  as  the 
GIG  environment  comes  to  realization. 

•  Service  Discovery:  “provides  for  the  publishing  and  discovery  of  enter¬ 
prise  services.”  Implementation  of  M-COP  services  will  require 
publishing  of  service  descriptions  in  accordance  with  standards  estab¬ 
lished  for  the  GIG.  Many  of  the  policy  issues  relating  to  implementa- 
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tion  of  the  M-COP  on  the  GIG  were  described  in  Blais  et  al.  (2005c). 
Particular  attention  must  be  given  to  requirements  of  the  DOD  Defense 
Discovery  Metadata  Specification  (DDMS)  (DOD  2005),  providing  the 
common  set  of  descriptive  metadata  elements  to  be  associated  with 
each  data  asset.  All  data  assets  on  the  GIG  must  be  described  with 
metadata  made  visible  to  the  GIG  service  discovery  capability.  In  accor¬ 
dance  with  current  Web  service  standards  adopted  for  the  GIG,  the  M- 
COP  services  will  be  described  using  the  Web  Services  Description  Lan¬ 
guage  (WSDL)  for  use  by  other  systems/  applications. 

•  Identity  Management  (People  and  Device  Discovery):  “the  federated 
set  of  capabilities  for  uniquely  identifying,  finding,  and  publishing 
white  pages  information  on  people  and  non-people  identities  within 
the  GIG  Web  Services  Environment.”  Users  of  the  M-COP  will  be 
granted  access  to  ground  vehicle  mobility  services  through  establish¬ 
ment  of  roles,  authentication,  and  authorization  processes  imple¬ 
mented  on  the  GIG.  Identity  Management  services  will  maintain  neces¬ 
sary  information  on  users.  As  a  supporting  service  to  other  applica¬ 
tions,  the  M-COP  may  not  need  to  deal  with  Identity  Management  ser¬ 
vices  directly,  as  those  interactions  will  be  coordinated  by  the  using 
application. 

•  Metadata  Services:  “provides  the  ability  for  DOD  Enterprise  systems 
to  discover  (publish,  make  visible,  and  access)  and  manage  various 
metadata  artifacts  critical  to  a  system  and/or  person’s  access  and  abil¬ 
ity  to  exchange  and  understand  data  components  within  the  enter¬ 
prise.”  The  M-COP  will  use  Metadata  Services  to  make  its  own  meta¬ 
data  artifacts  known  to  the  GIG  enterprise.  This  will  primarily  occur 
through  registration  of  data  models  and  ontologies,  as  well  as  meeting 
the  DDMS  requirements  indicated  above.  As  the  M-COP  evolves, 
maintenance  of  metadata  artifacts  through  these  GIG  services  will  be 
important  to  coherence  of  the  services  and  data  over  time. 

•  Mediation  Services:  “the  capability  to  transform  data”  including 
“simple  transformations”  such  as  transforming  XML  using  Extensible 
Stylesheet  Language  (XSL),  providing  adaptors  that  transform  data 
going  to/from  legacy  applications  or  other  non-standard  interfaces, 
orchestrating  the  flow  between  services,  and  “data  aggregation  or 
fusion.”  M-COP  capabilities  depend  upon  information  from  a  number 
of  diverse  sources.  These  are  discussed  in  the  M-COP  project  Second 
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Interim  Report  (Blais  et  al.  2005b)  and  indicated  in  the  following 
discussion  of  services  to  be  provided  by  M-COP  and  services  needed  by 
the  M-COP  that  are  to  be  provided  by  other  GIG  domains.  In  those 
areas  where  the  M-COP  is  not  dealing  directly  with  the  native  data  for¬ 
mat  of  a  particular  system  or  application,  it  will  make  use  of  GIG 
Mediation  services  to  make  necessary  data  transformations.  In 
addition,  some  M-COP  capabilities  will  be  obtained  through  coordi¬ 
nated  sequences  of  service  calls  to  other  domains.  The  orchestration  of 
those  calls  and  data  transformations  that  may  occur  within  the  chain 
will  be  coordinated  through  GIG  Mediation  services. 

•  Service  Security:  “provides  security-related  services,”  including 
“authentication,  authorization,  and  attribute  retrieval.”  Service  Secu¬ 
rity  services  will  ensure  that  only  authorized  users  (and,  by  extension, 
other  software  applications)  are  able  to  access  the  M-COP  data  and  ser¬ 
vices.  Service  Security  services  will  operate  across  all  GIG  processes. 

Use  of  GIG  enterprise  services  by  the  M-COP  is  not  expected  to  be  unique 
in  any  way,  but  will  reflect  best  practices  (i.e.,  in  accordance  with  policies 
enforced  by  ECS)  for  applications  operating  in  the  GIG  environment  that 
deploy  services  for  use  by  other  domains,  while  employing  GIG  CES  and 
services  from  other  domains. 

Services  Provided  by  the  M-COP 

The  M-COP  can  be  viewed  as  a  general  service  that  provides  data  mining 
mapping,  mediation,  and  storage,  where  information  from  disparate 
sources  in  a  variety  of  formats,  some  previously  captured  in  other  data 
models,  is  synthesized  and  interpreted  with  respect  to  mobility.  For  exam¬ 
ple,  other  users  may  need  to  find  a  supply  route  with  a  low  probability  of 
encountering  improvised  explosive  devices.  M-COP  can  be  a  source  for 
this  integrated  product,  performing  a  number  of  other  information 
accesses  on  behalf  of  the  requesting  user  (e.g.,  to  access  data  from  an 
“intelligence/threat”  service  as  well  as  accessing  a  route  finding  service). 

As  a  special  service  provider,  specific  products  or  sets  of  data  for  use  by 
other  services  can  be  produced.  Table  2  lists  potential  services  that  can  be 
provided  by  or  are  supported  by  the  M-COP.  It  should  be  noted  that  none 
of  these  products  are  static,  but  are  dynamic,  with  changes  based  on  the 
BOS,  battlespace  environment,  etc. 
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One  area  for  further  study  is  the  possibility  of  M-COP  providing  services 
that  result  in  formulation  of  Military  Scenario  Definition  Language 
(MSDL)  files  for  use  in  initializing  MSDL-capable  systems  (M&S  or  BC) 
(Surdu  et  al.  2005).  The  Simulation  Interoperability  Standards  Organiza¬ 
tion  (SISO)  is  currently  in  the  process  of  advancing  the  MSDL  specifica¬ 
tion  to  international  standard  status.  If  successful,  MSDL  use  across  M&S 
and  BC  systems  is  likely  to  grow  in  coming  years.  The  M-COP  can  provide 
movement  route  information  and  other  relevant  ground  vehicle  mobility 
information  to  insert  into  MSDL  files  for  a  particular  operational  use.  An 
extension  to  the  M-COP  services  identified  in  Table  2  would  be  generation 
of  movement  orders  from  the  planning  activities.  These  orders  could  be 
expressed  in  the  Battle  Management  Language  (BML),  a  common 
language  for  plans  and  orders  applicable  to  live,  constructive,  and  robotic 
forces.  BML  is  also  undergoing  standardization  through  SISO  under  the 
name  Coalition  Battle  Management  Language  (C-BML)  (Blais  et  al. 
2005d). 


Table  2.  Services  that  can  be  provided  by  the  M-COP. 


Service  Name 

Description  (sample  input,  output,  other  information  requirements) 

Ground  Vehicle/Unit 
Route  Finding  Products 

Input:  Start  and  end  points,  way  points,  re-supply  or  refueling  points,  unit  echelon, 
composition,  or  formation  threat  locations,  threat  range  of  influence,  cultural 
considerations,  criteria  (mission,  best  speed,  best  cover  and  concealment,  best 
communication  availability,  on-,  off-road  or  combined,  etc.). 

Requires:  Maneuver  Network  Analysis  Product  (see  below),  Combat  Service 

Support  (CSS)  data,  and  Intel  data. 

Note:  Can  also  be  used  by  Intel  for  threat  course  of  action  analysis.  Includes 
ability  for  modifying  route  finding  cost  functions  (types  of  areas  to  avoid).  Can  be 
accessed  for  dynamic  rerouting. 

Output  (example):  Best  routes  based  on  user  provided  constraints  (ala  annotated 
map  directions  available  on  the  World  Wide  Web),  output  as  strip  map  or  text 
based  turn-by-turn  direction,  maneuver  decision  points,  estimates  of  fuel 
consumption,  movement  timeline.  Route  trafficability  analysis  and  classification, 
military  load  classes  (MLC),  capacity  (tons/hr)  performed  against  unit  type.  Used 
for  planning  (course  of  action,  war  gaming,  and  execution). 

Obstacle  Locations  and 
Status  Report 

Input:  Types  of  obstacles,  area  of  interest,  timeframe  of  interest  (in  case  of 
planned  missions  that  would  create  obstacles),  vehicle  types,  breaching  assets. 
Requires:  Terrain  data. 

Output:  Obstacle  locations  and  status  (%  completion  or  %  breached,  breachable, 
and  required  assets  to  breach),  a  reflection  of  standard  military  engineer  obstacle 
analysis,  or  bypass. 

Bridge  Locations  and 
Status  Report 

Input:  Bridge  identifier  (need  globally  unique  identifiers),  or  requesting  bridge 
status  and  location  information  in  an  area  of  interest  and  timeframe  (in  case 
there  are  planned  operations  to  do  bridging,  repair  a  bridge,  or  destroy  a  bridge). 
Requires:  Terrain  data,  Intel  (Battle  Damage  Assessment). 

Output:  Text  data  relating  to  MLC,  traffic  conditions,  security,  Stability  and  Support 
Operations  (SASO). 
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Table  2  (cont.).  Services  that  can  be  provided  by  the  M-COP. 


Service  Name 

Description  (sample  input,  output,  other  information  requirements) 

Choke  Point  Analysis 
Report 

Input:  Area  of  interest,  timeframe,  unit  size  and  formation,  mission,  threat  range 
of  influence. 

Requires:  Terrain  data,  weather  data,  obstacle  report,  and  Intel  data. 

Note:  May  be  combined  with  Obstacle  report,  to  plan,  predict  obstacle  locations. 
Output:  Those  areas  where  maneuver  operations  are  at  risk  of  disruption 
(disruption  from  enemy,  civilians,  other  friendly  forces). 

Key  Terrain  for 

Maneuver  Report 

Inputs:  Area  of  interest,  unit  size,  mission. 

Requires:  Terrain  data,  weather  data,  and  perhaps  Obstacle,  Bridge,  and  Choke 
point  service  output. 

Output:  Specific  areas,  terrain  features,  and  facilities  that  are  key  for  maneuver 
(inverse  for  preventing  maneuver). 

Maneuver  Network 
Analysis  Product 

Input:  Area  of  Interest,  timeframe,  cover  and  concealment,  key  terrain,  choke 
points,  obstacles,  bridge  data,  mission,  SASO. 

Requires:  Terrain  data  (features,  soils,  and  ground  state),  weather— visibility, 
precipitation— vehicle  speed  predictions. 

Note:  While  a  geospatial  tool  such  as  C/JMTK  with  a  human-in-the-loop  will  be 
required  to  develop  a  maneuver  network,  once  the  product  is  made  it  should  be 
available  in  a  standard  format. 

Output:  A  maneuver  network  or  “graph.” 

Avenue  of  Approach 
Analysis  Report 

Input:  Area  and  time  of  interest,  unit  size,  objectives,  choke  points,  obstacles, 
control  measures  (unit  boundaries,  other  command,  and  cultural  boundaries). 
Requires:  Terrain  data. 

Output:  Coordinates  for  use  in  producing  graphics  depicting  avenues  of  approach. 

Command-Civilian- 
Cultural  Weather 

Mobility  Forecast 

Report 

Input:  Area  and  time  of  interest. 

Requires:  Terrain  data,  Intel  data  (IED  activity,  civilian  disposition,  etc.),  weather 
data,  command  road  restrictions,  and  road  closures. 

Output:  Text  based  report  (forecast)  of  estimated  locations  of  heavy  traffic,  civilian 
crowds,  and  weather  effects,  takes  into  account  market  days,  rush  hour, 
neighborhood  affiliations,  hostile  areas,  etc. 

Critical  Maneuver 
Information  Report 

Input:  Route  plan,  route  finding  constraints,  forecasted  weather,  threat  analysis. 
Requires:  Maneuver  Network  analysis,  terrain  data,  and  Intel  data. 

Output:  A  list  of  key  data  parameters  or  assumptions  that,  if  determined  to  be 
incorrect,  will  adversely  affect  the  maneuver  plan. 

Areas  of  Unrestricted, 
Restricted  and  Severely 
Restricted  Movement 
Product 

Input:  Area  and  time  of  interest,  unit  size,  vehicle  types. 

Requires:  Terrain  data,  mobility  analysis. 

Output:  Polygonal  areas  which  can  be  depicted  using  standard  graphical  symbols. 

Services  Provided  by  Other  COIs  to  Support  the  M-COP 

Table  3  describes  data  and  services  that  the  M-COP  will  expect  from  other 
domains,  categorized  here  by  the  BOS.  Winters  and  Tolk  (2005)  discusses 
the  development  of  some  prototype  services  (Blue  Force  Tracking  and 
Global  Force  Management)  that  can,  in  theory,  provide  some  of  the  informa¬ 
tion  described  below.  Both  of  those  prototypes  were  based  on  the  C2IEDM. 
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Table  3.  Services  from  other  domains  required  by  the  M-COP. 


Battlefield  Operating  System 
(BOS) 

Description  of  data,  information  required  from  services  within  the  BOS  by  M- 
COP  services* 

Mobility  /  Countermobility/ 
Survivability 

Terrain  products  and  data: 

•  Locations  of  terrain  features  and  facilities,  and  their  attributes. 

•  Current  and  projected  soil  condition  (temperatures,  soil  strength). 

•  Line-of-sight,  cover,  and  concealment  ratings. 

•  Elevation,  slope,  trafficability  (vehicle  speed  predictions), 
vegetation. 

•  Bridge  conditions,  road  surface  conditions,  road  load  capacity. 

Engineer  products: 

•  Ability  (time  and  resources  required)  to  breach  minefields  and 
other  obstacles,  repair  or  emplace  bridges,  repair  roads. 

•  Ability  (time  and  resources  required)  to  emplace  minefields  and 
other  obstacles. 

•  Planned  or  in-process  engineer  operations. 

Command  and  Control 

•  Friendly  force  locations,  unit  size. 

•  Mission  type,  units  involved. 

•  Unit  boundaries  (area  of  unit  operations/influence). 

•  Control  measures,  objectives. 

Air  Defense 

•  Air  defense  coverage  areas  (where  maneuver  can  be  protected 
from  air  attack). 

Maneuver 

•  None  identified,  the  M-COP  is  a  principal  provider  of  maneuver 
services. 

Intel 

•  Weather  products  (current  and  forecasted)— Visibility,  precipitation 
snow,  rain,  icing,  flooding  current  and  projected,  enemy  locations, 
strengths,  make-up,  range  of  influence. 

•  Location  of  obstacles. 

•  Threat  Analysis. 

•  Known/suspected  enemy  locations,  threat  template. 

•  Information  on  threat  capabilities  (What  sorts  of  weapons  do  they 
have?  How  far  can  they  see?  What  is  their  LOS  capability  from 
suspected  vantage  points?) 

•  Estimated  track  (route)  and  enemy  objective. 

•  Information  regarding  who  resides  in  what  neighborhood,  including 
neighborhood  affiliations  and  hostile  areas. 

•  Last  recon  from  given  area. 

Combat  Service  Support 

•  Resupply  locations,  times/schedules,  and  items. 

•  Medical  service  locations. 

•  Traffic  Control  Plans. 

•  Junctions  to  other  maneuver  network  types— Areal  Points  of 
Debarkation  (APODs),  Sea  Ports  of  Debarkation  (SPODs),  rail 
heads,  and  inland  ports. 

Fire  Support 

•  Planned  missions. 

*  The  data  or  products  listed  may  depend  on  services  and  products  from  other  BOS,  which  are  not  identified 
here  (e.g.,  road  condition  data  from  terrain  may  require  an  Intel  report  or  Engineer  analysis). 
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6  TASK  4:  COMMON  REFERENCE  MODEL 
REQUIREMENTS 


The  goal  of  the  final  task  in  the  M-COP  project  was  to  review  the  status  of 
command,  control,  communications,  computers,  and  intelligence  (C4I)- 
M&S  Reference  Object  Model  (CROM)  efforts  conducted  over  the  past  few 
years  to  align  C4I  and  M&S  data  models,  particularly  those  efforts  that 
have  described  portions  of  a  C4I  object  model  using  C2IEDM.  The  team 
compared  mapping  efforts  from  the  M-COP  data  modeling  efforts  in  the 
preceding  tasks  to  CROM  activities,  as  well  as  current  work  with  the  BML 
and  C2IEDM,  focusing  on  mobility-specific  information.  The  team  did  ini¬ 
tial  semantic  modeling  of  mobility  information,  moving  beyond  the  CROM 
Unified  Modeling  Language  (UML)  representations  to  preliminary 
ontological  representations  using  several  semantic  modeling  techniques, 
including  Formal  Concept  Analysis  (FCA)  and  description  logic  expres¬ 
sions  using  the  OWL.  The  work  resulted  in  the  beginning  of  an  advanced 
knowledge  model  expressed  in  OWL  for  the  mobility  domain. 

Additionally,  M-COP  data  model  components  were  mapped  to  the  next- 
generation  version  of  C2IEDM,  called  the  Joint  Consultation  Command 
and  Control  Information  Exchange  Data  Model  (JC3IEDM)  (MIP  2005b) 
to  identify  suggested  extensions  to  this  standard  coalition  data  model. 
Deliverables  for  Task  4  (provided  in  subsequent  sections  of  this  report) 
include  this  mapping  and  preliminary  OWL  model. 

Because  the  M-COP  data  model  was  not  fully  specified  by  the  conclusion  of 
Task  3,  further  definition  and  refinement  of  the  model  continued  in  Task 
4.  These  efforts  addressed  the  major  information  components  identified 
for  M-COP  and  are  discussed  below.  While  most  of  the  actual  data  ele¬ 
ments  are  defined  in  the  appendices,  these  next  sections  define  rationale 
and  sources  of  those  elements. 

One  issue  that  plagued  the  team  was  where  to  start  (see  Figure  2)  and 
what  tools  and  format  to  use  in  the  development  process,  as  numerous 
representations  and  mobility  models  currently  exist.  In  fact,  the  intent  of 
this  project  was  not  to  invent  yet  another  data  model  but  to  use  existing 
models  and  formalisms  to  the  extent  possible.  As  the  team  investigated 
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existing  models  (and  lack  of  them  for  some  portions  of  the  M-COP  data 
model)  and  considered  higher  order  representations,  it  became  clear  that  a 
basic  set  of  M-COP  data  or  concepts  was  required.  The  following  sections 
of  the  report  expand  the  descriptions  of  the  top-level  M-COP  data  model 
categories  and  define  the  initial  M-COP  specification. 


Figure  3  shows  a  diagram  as  a  take-off  from  entity-relationship  (ER)  dia¬ 
grams  for  the  M-COP  top-level  categories,  with  example  relationships  to 
classes  and  attributes,  as  well  as  between  categories  in  some  cases.  An  ER 
diagram  shows  graphically  “a  list  of  entity  types,  the  permissible  relations 
between  them,  and  some  of  the  constraints  on  those  relations”  (Sowa 
2000).  Chen  (1983)  discusses  the  issues  associated  with  developing  these 
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diagrams  and  their  relation  to  English  sentence  structure  and  database 
design.  We  did  not  follow  these  constructs  exactly  or  strictly  but  used  them 
as  a  guide  for  M-COP  relationship  designs.  The  ER-like  approach  is  used 
here  to  help  clarity  relationships  (represented  as  diamonds)  between  the 
M-COP  top-level  categories  and  those  classes  represented  by  other  data 
models  or  BOS  representations.  In  English,  for  example,  Route  Request 
has  one  or  more  constraints  (such  as  fastest  or  shortest)  along  with  attrib¬ 
utes  of  start  point  and  stop  point.  Terrain  has  zero  or  more  Obstacles  and 
Terrain  has  a  Trafficability  Surface  with  its  own  atti'ibutes.  Weather 
affects  Terrain  (e.g.,  a  snow  storm  will  cover  the  terrain  with  snow). 
Maneuver  Analysis  supports  the  development  of  the  Modified  Combined 
Obstacle  Overlay  (MCOO)  from  which  courses  of  action  can  be  analyzed. 
Note,  too,  that  Threat  Analysis  involves  much  of  the  activities  in  Maneu¬ 
ver  Analysis  and,  as  such,  there  is  a  relationship  between  these  categories. 
The  Utilities  category  is  not  shown,  as  it  provides  metadata  and  services 
supporting  the  other  categories.  Relationships  in  some  cases  are  directly 
related  to  M-COP  services  described  in  the  next  section.  This  diagram  is 
conceptual,  and  not  meant  to  include  every  relationship;  however,  the  dia¬ 
gram  and  relationships  should  be  kept  in  mind  as  the  M-COP  is  further 
described. 

M-COP  Top-Level  Categories 

The  major  categories  of  M-COP  information  identified  from  the  earlier 
tasking  are  described  in  greater  detail  in  this  section.  The  discussion 
includes  some  of  the  design  rationale  and,  where  applicable,  identifies 
existing  data  models  that  can  be  leveraged  to  satisfy  portions  of  the  M- 
COP  model.  Identifiying  existing  data  models  raises  the  question  of  how 
the  M-COP  data  model  can  be  populated  in  operational  use.  Determining 
these  data  sources  in  the  operational  (GIG)  environment  and  detailing 
how  the  data  will  be  accessed  to  populate  the  M-COP  are  beyond  the  scope 
of  the  current  project  and  are  recommended  areas  of  work  for  follow-on 
efforts  to  realize  the  M-COP  for  operational  employment. 

Terrain 

The  Terrain  category  of  the  M-COP  data  model  is  defined  as  the  natural 
and  man-made  features,  or  classes,  and  their  attributes  that  may  influence 
mobility  or  maneuver  of  ground  vehicles.  Terrain  includes  natural  and 
manmade  features;  manmade  features,  or  classes,  include  bridges,  roads, 
etc.  Man-made  features  are  defined  as  things  on,  in,  or  over  the  terrain 
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and  need  to  be  distinguished  from  the  underlying  physical  terrain  (ground 
and  water).  They  are  also  geometric  in  that  they  possess  three-dimensional 
shapes  but  are  located  relative  to  the  physical  terrain  region.  The  natural 
features  can  be  abstracted  as  a  geographic  region  having  features  and 
attributes  at  various  postings  (e.g.,  elevation,  vegetation,  soil  characteris¬ 
tics). 

Owing  to  the  extensive  past  and  present  work  in  the  area  of  terrain  data 
modeling,  representations  are  readily  available  that  meet  the  M-COP  pur¬ 
poses;  however,  a  common  mediation  format  is  needed  for  more  efficient 
design  of  data  interchange  across  multiple  systems  (Dobey  and  Eirich 
2005).  A  Visual  Object  Taxonomy  (VOT)  has  been  developed  that  provides 
“a  detailed  categorization  of  cultural  and  natural  objects”  (Bitters  2005). 
This  work  is  creating  distinct,  mutually  exclusive,  unambiguous,  and 
explicitly  defined  categories  “formulated  in  a  single  language”  (i.e., 
Webster’s  version  of  the  English  language).  Of  particular  interest  to  the 
C4I  and  M&S  communities,  the  taxonomy  was  developed  with  attention  to 
the  well-established  (and  heavily  vetted)  Synthetic  Environment  Data 
Representation  and  Interchange  Specification  (SEDRIS)  Environment 
Data  Coding  Standard  (EDCS)*,  Feature  and  Attribute  Coding  Catalog 
(FACC),  and  the  Digital  Feature  Analysis  Data  (DFAD).  The  VOT  is  a 
ready-made  structure  for  a  major  portion  of  the  M-COP  data  model.  The 
main  aspect  lacking  from  the  VOT  is  explicitly  characterizing  the  relation¬ 
ship  between  the  taxonomy  categories  and  ground  vehicle  mobility  (e.g., 
what  characteristics  make  objects  such  as  a  Road  effective  for  ground  vehi¬ 
cle  mobility  while  objects  such  as  Rubble  do  not?). 

Mobility  analysis  (calculation  of  maximum-ground-vehicle-capable  speed, 
acceleration  or  deceleration  on  a  given  area)  and  terrain  feature  concepts 
can  be  classified  as: 

•  Off-road:  where  issues  associated  with  staying  on  a  “path”  can  be 
ignored,  i.e.,  curvature. 

•  On-road:  where  path  curvature  must  be  considered,  and  it  can  be 
assumed  that  there  is  no  vegetation  to  be  avoided,  or  over-run. 

•  Obstacle  crossing:  where  wet  and  dry  gaps,  berms,  craters,  and  rubble 
piles  can  require  additional  analysis  in  which  ingress,  egress,  fording, 
and  swimming  effects  must  be  considered. 


*  http://www.sedris.org 
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•  Obstacle  breeching :  implies  operation  of  engineer  equipment  such  as 
bulldozers,  or  mine  plows. 

•  Amphibious  operation :  assumes  ground  vehicle  swimming;  issues  are 
current,  wave  heights,  obstacles,  ingress,  egress,  etc. 

To  develop  a  complete  list  of  terrain  features  and  their  attributes  required 
to  support  the  M-COP,  the  OneSAF  Objective  System  Environmental  Data 
Model  (OOS  EDM)  was  used  initially  as  a  basis.  The  OOS  EDM  is  based  on 
the  EDCS  feature  definitions  and,  by  using  their  classification  labels,  the 
Terrain  category  was  initially  divided  into  the  following  five  classes: 
REGION,  TRACT,  FACILITY,  SITE,  and  WATERBODY. 

In  doing  so,  it  became  clear  that  the  EDCS  definitions  that  may  have 
included  these  terms  were  not  consistent,  at  least  with  respect  to  mobility 
and  this  context.  Further  consideration  and  sorting  yielded  the  categories 
and  definitions  in  Table  4.  Note  that  some  of  them  are  hierarchical,  but  the 
intent  was  not  to  make  them  completely  so. 


Table  4.  Terrain  category  classes. 


Class 

Definition 

NATURAL_REGION 

A  NATURAL_REGION  is  an  area  of  terrain  that  contains  few  manmade  structures 
and  is  not  maintained  for  some  human  use  (e.g.,  cropland).  Mobility  analysis  of 
NATURAL_REGIONs  implies  cross-country  movement.  Roads  (including  trails  and 
railroads)  may  occur  through  regions  or  divide  regions.  SITEs  may  be  found,  but 
they  do  not  disrupt  movement  and  maneuver  to  the  extent  that  they  need  to  be 
accounted  for  in  route  planning. 

OPEN_TRACT 

OPEN_TRACTs  are  areas  that  may  be  used  for  some  human  purpose  that  has 
changed  their  character.  It  does  not,  in  general,  contain  SITEs  and  off-road 
movement  is  generally  assumed. 

FACILITY 

A  FACILITY  is  an  area  that  contains  more  than  one  structure  used  for  a  specific 
purpose  or  can  be  categorized  as  a  group.  These  structures  may  be  spread  out 
enough  so  that  there  are  roads,  trails,  or  open  space  that  allow  ground  vehicle 
movement  within  the  FACILITY,  possibly  off-road,  but  normally  on-road.  Off-road 
route  planning  within  a  FACILITY  will  need  to  take  into  account  individual  structures. 

SITE 

A  SITE  is  the  area  taken  up  by  an  individual  structure;  if  it  is  a  planned  structure, 
the  value  of  completion  must  be  greater  than  zero.  Ground  vehicles  are  assumed  to 
be  incapable  of  normal  travel  through  SITEs.  (SITEs  may  be  capable  of  being 
breached.) 

WATERBODY 

WATERBODYs  are  of  concern  for  ground  vehicle  movement  ingress,  egress,  fording, 
and  swimming.  WATERBODYs  may  contain  SITEs  and  FACILITYs,  which  enhance  or 
degrade  mobility  (swimming  or  fording). 

ROAD 

Terrain  intended  for  ground  vehicle  travel  between  two  locations.  A  ROAD  may  be  a 
series  of  connected  segments,  each  of  which  have  differing  attribute  values. 
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In  Appendix  A,  Table  Ai-Table  A6  list  enumerations  of  attributes  associ¬ 
ated  with  each  of  the  classes  defined  in  Table  4,  which  are  required  to  sup¬ 
port  the  M-COP.  These  enumerations  should  be  considered  allowable 
values  of  an  attribute  such  as  Feature_Type.  These  enumeration  values  are 
the  same  as  their  sources.  For  reader  ease,  the  formats  have  been  changed 
to  the  nomenclature  chosen  for  this  report.  The  intent  for  the  M-COP  is  to 
use  the  OOS  EDM  values;  the  other  sources  are  shown  only  for  compari¬ 
son.  The  terms  area,  line,  directed_line,  3d_line,  and  point  denote  the 
geometry  type. 

The  OOS  EDM  was  used  as  a  basis,  and  feature  types  from  the  FACC 
(DGIWG  2000),  along  with  those  specified  in  FM  21-31  (HQDA 1961)  are 
shown  aligned  (using  corresponding  terms).  The  Feature_Types  from  OOS 
EDM  should  be  the  chosen  M-COP  values.  While  the  location  and  type  of 
feature  is  required  for  Maneuver  Analysis  and  Route  Finding  (e.g.,  where 
is  a  pass  through  the  mountains?),  additional  information  (attributes)  is 
required  for  a  complete  mobility  analysis. 

The  attributes  associated  with  Terrain  classes  required  for  the  M-COP  are 
just  as  important  as  the  features  themselves.  Again  starting  with  OOS 
EDM  and  EDCS  attributes,  we  identified  eight  subclasses  to  contain  the 
information  necessary  to  conduct  mobility  and  maneuver  analysis  based 
upon  vehicle-terrain  interaction.  Along  with  the  EDCS  attributes,  inputs 
required  by  mobility  models  currently  used  by  the  U.S.  Army  (Ahlvin  and 
Haley  1992;  Baylot  et  al.  2005;  Richmond  et  al.  2005b;  Richmond  et  al. 
2006c)  were  considered.  The  subclasses  are: 

•  TRAFFICABILITYjSURFACE— a  set  of  attributes  associated  with  the 
terrain  surface  from  which  mobility  calculations  can  be  made;  they 
specifically  support  the  use  of  the  NATO  Reference  Mobility  Model 
(NRMM)  and  the  Standard  Mobility  (STNDMob)  Application  Program 
Interface  (API),  but  will  support  other  models  also  (Table  A7). 

•  TRAFFICABILITY_VEGETATION— attributes  associated  with  vegeta¬ 
tion  features  that  can  affect  mobility  (Table  A8). 

•  TRAFFICABILITY_WETGAPS— attributes  of  water  crossings  and  sites 
that  can  affect  mobility  (Table  A9). 

•  TRAFFICABILITY_DRYGAPS— attributes  of  gaps  (trenches  and 
ditches)  that  can  affect  mobility  (Table  A10). 

•  TRAFFICABILITY_ROAD— a  list  of  attributes  associated  with  the  M- 
COP  ROAD  class,  from  which  mobility  calculations  can  be  made. 
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Specifically  supports  the  use  of  the  STNDMob  API,  but  will  support 
other  models  also,  and  must  be  used  in  conjunction  with  the 
TRAFFICABILITY_SURFACE  subclass  (Table  All). 

•  TRAFFICABILITY_BRIDGES_TUNNEL— a  list  of  attributes  associated 
with  bridge  and  tunnels,  from  which  mobility  calculations  can  be 
made.  Specifically  supports  the  use  of  the  STNDMob  API,  but  will  sup¬ 
port  other  models  also,  and  must  be  used  in  conjunction  with  the 
TRAFFICABILITY_ROADS  subclass  (Table  A12). 

•  TRAFFICABILITY_RAILROAD— a  list  of  attributes  associated  with 
railroads,  from  which  mobility  calculations  can  be  made  (Table  A13). 
Currently,  this  list  of  attributes  can  stand  alone,  although  it  would  be 
desirable  to  merge  it  with  TRAFFICABILITY_ROAD  and 
TRAFFICABILITY_SURFACE. 

•  MANEUVER_URBAN— a  list  of  attributes  for  urban  areas  that  should 
be  considered  for  maneuver  in  urban  areas  (Table  A14).  Not  required 
for  trafficability  analysis. 

Table  Ay-Table  14  list  and  define  the  attributes  of  each  of  these 
subclasses,  which  should  be  associated  with  applicable  Terrain  classes. 

FMI  2-91.4  (HQDA  2005a)  specifies  information  about  urban  terrain  that 
should  be  considered  during  maneuver  planning.  While  no  automated 
system  to  our  knowledge  takes  this  information  into  account,  they  are 
required  as  part  of  the  M-COP.  The  EDCS  contains  attributes  that  describe 
this  information  by  the  type  of  urban  terrain  zone  (UTZ)  and  street  pat¬ 
tern.  These  two  attributes  currently  make  up  the  M-COP  Terrain  subclass 
MANEUVER_URBAN.  As  doctrine,  simulations,  and  BC  systems  evolve  to 
address  urban  operations,  this  category  may  need  to  be  expanded. 

To  reduce  the  size  of  the  OOS  EDM,  attributes  associated  with  a  particular 
feature  are  allowed  only  enumerations  that  are  appropriate  to  the  feature 
(e.g.,  a  Treed_Tract  has  a  vegetation  type,  but  the  allowable  values  are  lim¬ 
ited  to  types  of  trees).  Additionally,  not  all  of  the  OOS  features  have  the 
complete  set  of  M-COP  attributes;  however,  those  can  be  set  to  null  or 
default  values.  Similarly,  other  applications  interacting  with  the  M-COP 
need  to  be  aware  of  this  requirement.  For  the  M-COP  Terrain  attributes 
sets,  this  approach  was  not  taken. 

Slope  effects  also  need  to  be  considered;  the  determination  of  a  slope 
implies  directionality,  and  high-fidelity  mobility  models  use  the  current 
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vehicle  location  and  heading  to  determine  a  current  vehicle  pitch.  Lower- 
fidelity  models  used  for  planning  can  use  the  average  of  the  maximum, 
minimum,  and  level  slope  speeds  to  obtain  an  “Omni-speed”  prediction. 
Other  approaches  can  be  imagined.  In  any  case,  if  the  terrain  is  repre¬ 
sented  initially  as  polygons,  then  the  slope  is  inherent  in  the  three- 
dimensional  location  of  each  vertex.  The  spatial  location  and  extent  of  a 
feature  or  object  are  defined  through  the  use  of  a  “geometry.”  There  are 
many  geometry  data  models;  refer  to  the  Utilities  category  of  the  M-COP 
described  later  in  this  report. 

Once  speed  (or  acceleration/deceleration)  has  been  determined  for  all  ter¬ 
rain  “types”  in  an  area  of  interest,  severely  restricted,  restricted,  and  unre¬ 
stricted  terrain  can  be  identified,  the  Terrain  category  can  be  further 
classified,  and  a  maneuver  network  created  (see  Route  Finding  category 
section). 

Obstacles 

The  Obstacles  category  consists  of  those  Terrain  features  (classes)  or  other 
objects  or  conditions  that  disrupt  or  impede  movement  of  ground  vehicles. 
As  with  the  Terrain  category,  Obstacles  may  be  natural  (cliff,  ravine, 
swamp)  or  manmade  (minefield,  log  barricade,  rubble).  As  indicated, 
some  Terrain  classes,  whether  manmade  or  natural,  can  also  belong  to  the 
Obstacles  category  based  on  characteristics  that  cause  these  objects  to  dis¬ 
rupt  or  impede  movement  of  ground  vehicles.  Even  another  vehicle  can  be 
an  obstacle  to  ground  vehicle  mobility  under  certain  circumstances.  With 
an  automated  reasoned,  members  of  various  classes  can  be  automatically 
classified  as  Obstacles  based  on  their  properties;  for  example,  a  river  with 
certain  width,  current,  and  depth  property  values  can  be  classified  as  an 
Obstacle.  If  those  property  values  change,  say  during  a  drought,  then  the 
river  may  cease  to  be  an  obstacle.  Creating  a  lane  through  a  minefield  does 
not  cause  the  minefield  to  no  longer  be  a  minefield,  but  it  may  cause  it  to 
no  longer  be  an  obstacle  to  ground  vehicle  mobility.  The  ability  of  software 
to  perform  these  inferences  based  solely  on  the  abstract  description  of  the 
data  model,  rather  than  hard-coded  in  software  specialized  for  the  applica¬ 
tion,  is  one  of  the  merits  of  a  formalized  ontology  at  the  Logical  Theory 
level  of  the  ontology  spectrum. 


*  Reasoner,  something  that  can  find  new  facts  from  existing  data  (a.k.a.  reasoning) 
(http://en.wikipedia.org/wiki/Reasoner).  See  http://www.w3.org/2004/0WL/  for  a  list  of  available 


reasoners. 
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Like  the  Terrain  category,  Obstacles  are  also  fully  specified  in  existing  data 
models  that  can  be  re-used  for  M-COP.  Appendix  B  contains  tables  similar 
to  those  in  Appendix  A,  except  that  here  we  specify  these  Obstacles  as 
classes  (Table  Bi)  for  the  M-COP,  because  they  have  little  in  common  with 
each  other.  The  attributes  of  selected  Obstacle  category  classes  are  in  Table 
B2.  By  their  nature,  the  kinds  of  obstacles  identified  in  Appendix  B  were 
not  included  in  the  Terrain  category.  As  with  the  Terrain  category,  the 
OOS  EDM  was  used  as  a  basis  and  obstacle  types  from  the  FACC  (DGIWG 
2000),  along  with  those  specified  in  FM  21-31  (HQDA 1961)  are  shown 
aligned  (using  corresponding  terms)  for  comparison.  The  M-COP  Obstacle 
category  classes  are  those  in  the  OOS  EDM. 

Weather 

The  Weather  category  classes  developed  for  M-COP  are  shown  in  Table  5. 
The  Weather  category  consists  of  current  and  forecasted  weather  conditions 
that  affect  mobility  and  maneuver  (LIGHTING_AND_VISIBILITY*, 
PRECIPITATION).  The  Weather  category  has  a  similar  abstract  structure 
as  the  Terrain  category,  in  that  it  is  best  characterized  as  a  geographic 
region  having  certain  physical  and  temporal  characteristics.  Existing  Envi¬ 
ronmental  Data  Models  (EDMs)  provide  detailed  data  representations  that 
can  meet  M-COP  data  and  information  requirements. 


Table  5.  Weather  category  classes. 


Class 

Examples  of  Attributes 

Appendix  C 

PRECIPITATION 

Precipitation_Type,  Precipitation_Rate, 

Snow_Accumulation_Depth,  Accum_Precip 

Table  Cl 

ATMOSPHERE 

2m_Air_Temperature,  Maximum_Air_Temperature, 
Wind_Chill_lndex,  Lightning_Probability,  Route_Weather_Type 

Table  02 

WIND 

Wind_Direction,  Wind_Speed,  and  Wind_Gust_Speed 

Table  C3 

CL0UD_C0VER 

Information  on  clouds  including  Cloud_Type,  base  height,  and 
amount  of  cover 

Table  C4 

LIGHTING_AND_VISIBILITY 

Information  on  visibility  and  lighting  including  distance,  bearing, 
obscurants,  time  of  sunrise,  sunset,  moonrise,  moonset 

Table  C5 

ICING 

Probabil ity_Of_lcing,  Icingjntensity,  and  lcing_Type 

Table  06 

The  Weather  category  classes  were  developed  by  reviewing  a  series  of 
models  and  field  manuals  to  gather  the  pertinent  features.  Some  of  the 


*The  class  LIGHTING_AND_VISIBILITY  includes  lighting.  Even  though  it  is  not  weather  related  it  has  a 
great  effect  on  visibility. 
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field  manuals  from  which  the  category  classes  and  attributes  were  devel¬ 
oped  are  given  below: 

•  FM  5-33  Terrain  Analysis  (HQDA 1990). 

•  FM  34-81  Weather  Support  for  Army  Tactical  Operations  (HQDA 
1989). 

•  FM  34-81-1  Battlefield  Weather  Effects  (HQDA  1992). 

•  FM  34-130  Intelligence  Prepai'ation  of  the  Battlefield  (HQDA  1994). 

The  classes  and  attributes  were  also  identified  in  the  following  models. 

•  SEDRIS  EDCS.* 

•  OOS  EDM-AOS  components. 

•  Joint  Meteorology  and  Oceanography  (METOC)  Conceptual  Data 
Model  (JMCDM).+ 

•  Army  Integrated  Meteorological  System  (IMETS). 

•  MSDL. 

Complete  descriptions  of  the  attributes  of  these  classes  are  provided  in 
Appendix  C,  Tables  C1-C6. 

Maneuver  Analysis 

As  we  have  described,  Maneuver  Analysis  includes  analyses  related  to 
ground  vehicle  movement  with  respect  to  mission,  command  and  control, 
flow  of  operations,  local  culture,  and  other  considerations.  It  also  includes 
some  information  versus  raw  data  classes  required  for  the  analysis.  The 
focus  is  on  what  the  commander  needs  to  know  to  conduct  maneuvers  in 
the  battlespace  and  can  apply  to  friendly  and  threat  forces.  In  maneuver 
analysis,  the  need  for  assessment  of  higher-order  effects  resulting  from 
characteristics  at  the  data-level  of  the  environment  makes  the  Maneuver 
Analysis  category  different  from  the  Terrain,  Weather,  and  Obstacle 
categories.  The  Maneuver  Analysis  classes  are  not  features  of  the  terrain 
per  se,  but  are  representations  of  the  effects  of  the  terrain  on  ground  vehi¬ 
cle  mobility.  This  is  also  true  for  the  Threat  Analysis  and  Route  Finding 
categories. 


*  http://www.sedris.org/edcs.htm 

t  The  Joint  METOC  Conceptual  Data  Model  (JMCDM)  and  its  supporting  encyclopedia  are  a  subset  of  the 
DoD  Enterprise  Data  Model.  The  JMBL  schema  provides  an  XML  representation  of  the  JMCDM  and 
establishes  a  single  interface  for  requesting  and  retrieving  METOC  data. 
http://pao.cnmoc.navy.mil/scripts/public_JMCDM/home_pwd.pl 
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Some  researchers  have  observed  that  efforts  to  reach  common  terrain  and 
environment  models  have  been  focused  at  the  data  level  rather  than  at  the 
information  or  knowledge  level  (Galvin  et  al.  2005).  The  distinction  is 
important.  Systems  have  primarily  dealt  directly  with  the  raw  data  charac¬ 
terizing  a  geographic  region,  performing  various  processing  to  derive  some 
battlefield  effects  (such  as  line-of-sight).  Rather  than  having  such  informa¬ 
tion  available  directly,  numerous  systems  spend  processing  resources  to 
derive  the  higher-order  effects,  and  often  compute  those  results  over  and 
over  again.  Moreover,  the  raw  data  sets  can  be  extremely  large,  making  it 
very  inefficient  to  distribute  over  a  network.  The  ability  to  represent 
derived  products  could  prove  to  be  more  efficient  for  system  design. 

In  recognition  of  this,  a  parallel  and  complementary  effort  to  M-COP  has  been 
started  in  the  Engineer  Research  and  Development  Center  (ERDC)  Topog¬ 
raphic  Engineering  Center  (TEC)  to  define  a  data  model  for  a  Geospatial 
Battle  Management  Language  (GeoBML).  As  described  in  Galvin  et  al.  (2005):* 

ERDC  seeks  to  abstract  and  represent  terrain  and 
dynamic  environment  through  a  rich  set  of  discrete 
objects  (spatial  and  temporal)  and  relationships  to 
tactical  entities  and  tasks.  Instances  of  these  objects 
and  relationships  can  then  be  extracted  from  the  cur¬ 
rent  and  future  large  terrain  and  dynamic  environ¬ 
ment  datasets  and  databases— essentially  reducing 
large  terrain  data  sets  to  their  tactical  essence  and 
expressing  the  reduction  in  an  ontology  for 
interoperability  at  the  conceptual  level. 

Clearly,  emerging  ontology  development  for  the  GeoBML  effort  is  of  direct 
consequence  to  the  Maneuver  Analysis  category  of  the  M-COP  data  model. 
Several  information-level  “products”  were  identified  in  the  stakeholders’ 
analysis  (e.g.,  avenues  of  approach,  severely  restricted  areas,  mobility 
corridors,  and  choke  points).  These  are  not  features  of  the  terrain  per  se, 
but  representations  of  the  effects  of  the  terrain  on  ground  vehicle  mobility. 

Maneuver  Analysis  is  not  a  standard  term  found  in  military  publications 
such  as  FM  1-02,  Operational  Terms  and  Graphics  (HQDA  2003a),  and 


*  The  Coalition  Battle  Management  Language  (C-BML)  Study  Group  Final  Report  included  contributions 
from  a  number  of  researchers  in  the  C4I  and  M&S  communities.  The  particular  contribution  relating  to 
a  GeoBML  was  submitted  by  M.  Powers  of  the  ERDC  TEC. 
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no  existing  data  models  were  discovered.  Likewise,  there  is  no  detailed  dis¬ 
cussion  or  standard  operating  procedure  that  neatly  describes  how  to  do  a 
maneuver  analysis.  However,  there  are  several  processes  and  analyses  the 
Army  describes  that  are  associated  with  the  maneuver  analysis  category, 
and  the  team  depended  heavily  on  these  to  tease  out  concepts  for  maneu¬ 
ver  analysis  classes  and  associated  attributes. 

To  identify  the  classes  and  attributes  associated  with  the  Maneuver  Analy¬ 
sis  category,  we  began  by  focusing  on  what  the  commander  needs  to  know 
to  maneuver  in  the  battlespace,  as  was  the  subject  of  the  stakeholder’s 
analysis.  The  process  was  iterative  and  involved  organizing  potential  ele¬ 
ments  (data  and  information)  gathered  from  stakeholders,  reading,  and 
research  into  like  concepts  and  interrelationships.  The  Intelligence 
Preparation  of  the  Battlefield  (IPB)  process  and  terrain  analysis  proce¬ 
dures  provided  a  good  framework  from  which  to  identify  and  organize 
concepts.  FM  3-0,  Operations  (HQDA  2001a),  FM  3-90,  Tactics  (HQDA 
2001b),  and  FM  7-15,  The  Army  Universal  Task  List  (HQDA  2003b)  pro¬ 
vided  a  bigger  picture  context  in  how  the  concepts  apply. 

The  IPB  process  is  an  important  component  in  determining  where  forces 
can  and  would  want  to  maneuver  to  achieve  a  decisive  advantage  (define 
the  battlefield  environment  and  describe  the  battlefield’s  effects,  noted  as 
steps  1  and  2  of  the  IPB  process).  Terrain  analysis  involves  interpreting  the 
effects  of  terrain  on  military  operations  and  is  an  integral  part  of  the  IPB 
process.  There  are  field  manuals  dedicated  to  the  subject  of  terrain  analy¬ 
sis— e.g.,  FM  5-33,  Terrain  Analysis  (HQDA  1990),  and  Intelligence 
Preparation  of  the  Battlefield,  FM  34-130  (HQDA  1994)  and  FM  2-91.4 
(HQDA  2005a). 

Before  detailing  the  concepts  and  classes  identified  for  the  Maneuver 
Analysis  category,  it  is  important  to  discuss  the  means  by  which  the  team 
differentiated  elements  for  Maneuver  Analysis  versus  Threat  Analysis. 
Many  of  the  concepts  pertaining  to  where  the  threat  will  be  located  or  will 
try  to  engage  friendly  forces  and  so  forth  are  represented  as  classes  and 
subclasses  in  the  Maneuver  Analysis  category  rather  than  in  the  Threat 
Analysis  category.  The  rationale  used  to  determine  classes  of  Maneuver 
Analysis  versus  Threat  Analysis,  as  these  are  highly  intertwined  from  an 
M-COP  perspective,  was  based  on  the  overarching  steps  of  the  IPB  proc¬ 
ess.  The  first  two  steps  of  the  IPB  process  are  to  define  the  battlefield  envi¬ 
ronment  and  describe  the  battlefield’s  effects.  These  were  used  to  guide 
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components  of  Maneuver  Analysis.  The  Threat  Analysis  data  model  devel¬ 
opment  was  guided  by  the  third  and  fourth  steps  of  the  IPB  process:  evalu¬ 
ate  the  threat  and  determine  threat  courses  of  action,  with  a  focus  on 
mobility-related  components.  There  are  natural  linkages  between  the 
Maneuver  Analysis  and  Threat  Analysis  categories. 


The  Modified  Combined  Obstacle  Overlay  (MCOO)  is  part  of  describing 
the  battlefield’s  effects  on  threat  and  friendly  forces,  is  a  product  of  the 
IPB  process,  and  includes  maneuver  analysis.  An  example  is  shown  in 
Figure  4.  The  MCOO  is  developed  for  a  geographic  area  and  depicts  ave¬ 
nues  of  approach  (AA),  mobility  corridors  (MC),  mobility  estimates  as 
unrestricted,  restricted,  or  severely  restricted  areas,  identifies  key  terrain, 
potential  engagement  areas  (EA),  and  obstacles,  for  example  (FM  34-130, 
HQDA 1994).  Many  of  these  elements  were  noted  during  the  collaborative 
brainstorming  sessions  with  stakeholders  as  elements  needed  for 
determining  where  to  maneuver  in  the  battlespace. 


Figure  4.  Modified  Combined  Obstacle  Overlay  developed  during  Mission  Analysis  Practical 
Exercise  by  officers  at  Fort  Huachuca  participating  in  the  Military  Intelligence  Officer 
Advanced  Course  (March  1996). 
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Within  the  area  of  operations  (AO),  it  is  important  to  identify  the  obsta¬ 
cles,  both  military  and  natural,  as  these  have  an  impact  on  mobility  and 
maneuver.  The  obstacles  are  referenced  in  the  Maneuver  Analysis  category 
but  are  obtained  from  the  Obstacle  category  where  the  classes  and  attrib¬ 
utes  are  organized  and  detailed. 

Trafficability  classifications  are  also  key  in  analyzing  maneuver  in  the  AO. 
These  are  typically  categorized  as  unrestricted,  restricted,  and  severely 
restricted  mobility,  based  on  analysis  of  regions  or  sectors  of  the  terrain. 

As  taken  from  FM  34-130,  unrestricted  terrain  does  not  restrict  move¬ 
ment,  and  there  is  no  need  to  enhance  mobility  through  these  areas.  Thus, 
relatively  flat,  open  terrain  or  improved  roads  would  be  characteristics  of 
unrestricted  terrain.  Restricted  terrain,  as  the  term  implies,  offers  impedi¬ 
ments  to  movement.  In  such  areas,  movement  may  require  more  maneu¬ 
vering  around  slower  going  areas  or  terrain  may  be  more  hilly  and  rough. 
Like  restricted  terrain,  severely  restricted  terrain  impedes  movement,  but 
to  a  more  significant  degree.  This  type  of  terrain  can  be  characterized  by 
steep  slopes,  soft  soils,  or  the  presence  of  several  obstacles,  or  all  three. 
Additionally,  there  are  models  such  as  the  NATO  Reference  Mobility 
Model  (NRMM)  that  can  be  applied  to  provide  maximum  speed  potential 
estimates.  In  keeping  with  this,  we  developed  a  class  called 
TRAFFICABILITY_SEGMENT  (Table  D2).  Consider,  in  a  maneuver  analy¬ 
sis,  analyzing  the  area  of  operations  for  terrain  impediments.  Conceptu¬ 
ally,  a  human  or  a  computer  can  break  the  terrain  into  sectors  and  assign 
trafficability  estimates.  This  is  also  similar  to  the  speed  attribute  assigned 
to  the  edge  of  a  maneuver  network  (see  the  Route  Finding  category  sec¬ 
tion).  On  examining  Figure  4,  one  can  see  how  determining  severely 
restricted  and  restricted  terrain  influences  movement  and  maneuver  and 
is  a  key  concept  within  maneuver  analysis. 

Avenues  of  approach  (AA)  for  the  ground  are  defined  in  FM  1-02  as 
“...ground  route  of  an  attacking  force  of  a  given  size  leading  to  its  objective 
or  to  key  terrain  in  its  path”  (HQDA  2003a).  The  AAs,  then,  are  critical 
elements  in  maneuver  analysis.  The  AAs  are  selected  based  on  mission, 
objective,  and  trafficability,  among  other  things.  The  corresponding  pro¬ 
posed  class  is  GROUND_AVENUE_OF_APPROACH  (Table  D3)  and  is 
associated  with  an  AO.  Figure  4  depicts  AAs  selected  based  on  west  to  east 
movement  toward  objectives  in  the  southern  region  of  the  AO  (large,  open 
arrows).  One  can  see  how  the  trafficability  and  obstacles  influence  AA 
determination. 
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Another  important  concept  is  mobility  corridors.  Mobility  corridors  (MC) 
are  “Areas  where  a  force  will  be  canalized  due  to  terrain  restrictions.  They 
allow  military  forces  to  capitalize  on  the  principles  of  mass  and  speed  and 
are  therefore  relatively  free  of  obstacles”  (HQDA  2004).  The  class 
MOBILITY_CORRIDOR  (Table  D4)  is  used  to  convey  information  about 
MCs  associated  with  the  AO.  The  MCs  affect  AAs  and,  as  graphical  sym¬ 
bols,  convey  information  about  the  size  of  the  force,  or  frontage,  that  can 
move  through  an  area.  The  MCs  are  determined  by  analyzing  the  terrain 
for  large  obstacles  and  restricted  or  severely  restricted  areas.  Thus,  we  also 
created  a  class  called  AVENUE_OF_APPROACH_CHANNELIZER  (Table 
D5),  which  conveys  data  and  information  about  the  features  associated 
with  the  MCs.  Figure  4  shows  MCs  of  different  widths  and  restrictions. 

Because  some  elements  needed  for  maneuver  analysis,  such  as  cover  and 
concealment,  are  characteristic  of  segments  of  the  AA  versus  of  the  entire 
AA,  we  also  created  a  class  called  AVENUE_OF_APPROACH_SEGMENT 
(Table  D6).  The  segments  are  numbered  and  tied  to  a  particular  AA. 
Attributes  associated  with  this  class  include  intervisibility,  cover,  and  con¬ 
cealment  as  estimated  in  percent.  However,  these  can  also  be  categorized 
as  good,  fair,  poor  or  by  some  other  method. 

Key  terrain  is  important  to  identify  in  maneuver  analysis  and  is  defined  in 
FM  1-02  as  “(DOD,  NATO)  any  locality,  or  area,  the  seizure  or  retention  of 
which  affords  a  marked  advantage  to  either  combatant”  (FM  1-02,  HQDA 
2003a).  As  noted  above,  key  terrain  can  influence  the  placement  of  AAs. 
The  associated  class  for  the  Maneuver  Analysis  category  is  KEY_TERRAIN 
(Table  D7). 

As  part  of  determining  where  to  maneuver,  it  is  important  to  assess  where 
you  would  want  to  engage  the  enemy,  as  well  as  where  the  enemy  might 
have  an  opportunity  to  engage  friendly  forces  (engagement  area).  As 
defined  in  FM  1-02,  an  engagement  area  (EA)  is  “an  area  where  the  com¬ 
mander  intends  to  contain  and  destroy  an  enemy  force  with  the  massed 
effects  of  all  available  weapons  and  supporting  systems”  (HQDA  2003a). 
Characteristics  of  observation  and  fields  of  fire,  which  are  influenced  by 
terrain  and  elevation,  affect  potential  engagement  areas.  This  concept  is 
reflected  in  the  class  ENGAGEMENT_AREA  (Table  D8).  Several  potential 
EAs  are  shown  in  Figure  4. 
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Maneuver  analysis  is  also  concerned  with  the  progression  of  units  over 
time.  These  are  generally  depicted  as  time  phase  lines  (TPL),  lines  indicat¬ 
ing  the  flow  of  the  operation  (based  on  a  course  of  action),  and  the 
progression  of  units  at  particular  time  intervals  relative  to  the  start  time 
for  the  movement.  H-Hour  typically  indicates  the  start  time  and  H+15 
indicates  progression  after  15  minutes  have  elapsed,  etc.  (HQDA  2003a). 
This  class  is  denoted  as  TIME_PHASE_LINES_H  (Table  D9).  TPLs  are 
named  and  are  associated  with  an  AO  and  AAs. 

A  summary  of  the  classes  for  the  Maneuver  Analysis  category  is  given  in 
Table  6.  The  classes,  attributes,  definitions,  and  data  types  can  be  found  in 
Appendix  D,  Table  Di-Table  D9. 


Table  6.  Maneuver  Analysis  category  classes. 


Class 

Definition 

Appendix  D 

AREA_OF_OPERATIONS 

“An  operational  area  defined  by  the  joint  force 
commander  for  land  and  naval  forces.”  (FM  1-02). 
Abbreviated  as  AO. 

Table  D1 

TRAFFICABILITY_SEGMENT 

An  area  of  defined  trafficability  of  a  portion  of  the 
AREA_0F_0PERATI0NS  (e.g.  severely  restricted). 
Abbreviated  as  TS. 

Table  D2 

GROUND_AVENUE_OF_APPROACH 

"(DOD)  ground  route  of  an  attacking  force  of  a  given  size 
leading  to  its  objective  or  to  key  terrain  in  its  path.”  (FM 
1-02).  Abbreviated  as  AA. 

Table  D3 

MOBILITY_CORRIDOR 

"(DOD)  Areas  where  a  force  will  be  canalized  due  to 
terrain  restrictions.  They  allow  military  forces  to 
capitalize  on  the  principles  of  mass  and  speed  and  are 
therefore  relatively  free  of  obstacles."  (FM  1-02). 
Abbreviated  as  MC. 

Table  D4 

AVENUE_OF_APPROACH_CHANNELIZER 

Point  or  areal  terrain  feature  of  the  AA  that  will  cause 
channelization.  This  could  be  a  severely  restricted  area, 
a  forest,  a  river,  etc.  (FM  1-02) 

Table  D5 

AVENUE_OF_APPROACH_SEGMENT 

Segmented  areas  of  the 
GROUND_AVENUE_OF_APPROACH. 

Table  D6 

KEY_TERRAIN 

“Any  locality,  or  area,  the  seizure  or  retention  of  which 
affords  a  marked  advantage  to  either  combatant."  (FM 
1-02) 

Table  D7 

ENGAGEMENT_AREA 

"An  area  where  the  commander  intends  to  contain  and 
destroy  an  enemy  force  with  the  massed  effects  of  all 
available  weapons  and  supporting  systems.  Also  called 
EA."  (FM  1-02).  Abbreviated  as  EA. 

Table  D8 

TIME_PHASE_LINES_H 

Lines  indicating  the  flow  of  the  operation  (based  on  a 
course  of  action)  and  the  progression  of  units  at 
particular  time  intervals  relative  to  the  start  time  for  the 
movement.  H-Hou r  typically  indicates  the  start  time  and 
H+15  indicates  progression  after  15  minutes  have 
elapsed,  etc.  (FM  1-02).  Abbreviated  as  TPL. 

Table  D9 
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Route  Finding 

Route  Finding  is  the  process  of  finding  a  minimum-cost  route  for  a  force 
from  an  origin  to  a  destination  in  a  maneuver  search  space  that  meets  con¬ 
straints  specified  in  a  route  request.  In  this  report,  route  requests  are  cre¬ 
ated  during  Maneuver  Analysis;  near-term  route  finding  to  avoid  dynamic 
obstacles  is  not  considered.  Several  concepts  are  involved  in  route  finding. 
One  is  trafficability— the  potential  for  movement  of  a  force  over  a  piece  of 
terrain.  As  mobility  and  maneuver  involve  movement  from  one  point  to 
another,  the  idea  of  connectedness  from  one  area  to  another  in  terms  of 
trafficability  is  necessary.  A  maneuver  network  graph*  with  assessments  of 
trafficability  on  each  graph  edge  provides  a  context  for  maneuver  potential 
in  the  area  of  operations.  Edges  represent  contiguous  traffi cable  terrain 
features.  Impassable  obstacles  are  represented  by  the  absence  of  edges  and 
negotiable  obstacles  are  represented  by  edges  attributed  with  the  assessed 
trafficability  of  the  obstacle.  Nodes  delimit  changes  in  trafficability 
between  adjacent  edges.  A  graph  composed  of  such  edges  and  nodes  pro¬ 
vides  a  maneuver  search  space  for  determining  a  minimum-cost  route  for 
a  group  of  vehicles  as  defined  in  the  Force  section.  The  context  for  deter¬ 
mining  a  maneuverable  route  is  built  with  elements  from  two  sources.  One 
source  is  the  representation  of  maneuver  considerations  other  than 
trafficability,  such  as  concealment,  in  the  maneuver  network  graph  by 
additional  edge  attribution.  Another  source  for  maneuver  considerations  is 
maneuver  analysis.  These  results  are  expressed  in  the  form  of  constraints 
or  “costs”  on  the  route  assessment  calculations. 

For  a  route  to  be  suitable  for  a  maneuver,  it  must  not  only  be  traversable, 
it  must  also  comply  with  movement  restrictions  or  constraints  resulting 
from  maneuver  analysis.  Examples  of  constraints  include  maximum  range, 
proximity  limits  to  specific  terrain  or  terrain  types,  proximity  limits  to 
areas  influenced  by  threat  units,  waypoints  to  visit,  unit  boundaries  and 
other  control  measure  limitations  on  operations,  concealment  require¬ 
ments,  obstacles  unknown  at  network  graph  compilation  time,  and  forma¬ 
tions  in  which  the  force  will  travel.  Often,  one  constraint  cannot  be  met 
without  violating  another  constraint.  As  constraints  cannot  always  all  be 
met  simultaneously,  each  constraint  must  be  weighted  against  other  con¬ 
straints  during  maneuver  analysis.  This  weighting  must  be  taken  into 


*  Graph  (data  structure)  Definition:  A  set  of  items  connected  by  edges.  Each  item  is  called  a  vertex  or 
node.  Formally,  a  graph  is  a  set  of  vertices  and  a  binary  relation  between  vertices,  adjacency. 
http://www.  n  ist.gov/dads/HTM  L/gra  ph  .htm  I 
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account  in  finding  a  traversable  route  that  best  meets  the  constraints  of 
the  route  request. 

Another  concept  in  route  finding  is  that  of  a  force.  Because  route  finding  is 
intended  for  traversal  by  some  type  of  unit  or  force,  it  is  important  to  know 
the  type  of  vehicles  in  the  force  and  the  width  of  the  formation  in  which 
the  force  will  travel.  Force  attribution  contains  the  type  of  vehicles,  as  well 
as  the  width  of  formations  (see  Force  category  in  next  section). 

Development  of  the  route  finding  data  model  mirrors  the  development  of 
the  M-COP  data  model.  First,  a  set  of  questions  intended  to  bound  the 
model  (Noy  and  McGuinness  2001)  were  answered.  The  initial  inventory 
of  terms  used  in  the  Route  Finding  data  model  is  derived  from  the  internal 
data  model  of  the  Battlespace  Terrain  Reasoning  and  Awareness  (BTRA) 
software  (Hall  and  Swann  2005).  That  inventory  of  terms  was  expanded 
with  terms  collected  from  previous  M-COP  literature,  stakeholder  sessions 
as  described  above,  informal  software  documentation  for  OOS  (Condon 
2002),  and  a  report  on  maneuver  representation  in  simulations  (SAIC 
1999).  These  terms  were  included  on  the  basis  of  their  relevance  to  route 
finding.  The  terms  were  then  compared  to  elements  in  the  ER  diagram  in 
Figure  3.  If  a  term  still  fit  within  the  scope  of  route  finding  as  bounded  by 
the  competency  questions  and  was  not  a  synonym  of  another  term,  it 
remained  in  the  inventory.  Finally,  the  terms  were  ordered  into  a  hierar¬ 
chy  of  classes  and  subclasses.  Results  are  included  in  Appendix  E,  Table 
El,  and  the  proposed  Route  Finding  classes  are  in  Table  7. 


Table  7.  Route  Finding  category  classes. 


Class 

Definition 

ROUTE 

“The  prescribed  course  to  be  traveled  from  a  specific  point  of  origin 
to  a  specific  destination.”  -  FM  3-90 

ROUTE_REQUEST 

A  request  for  a  route  through  a  maneuver  network. 

CONSTRAINT 

A  requirement  that  should  be  met  by  the  route. 

MANEUVER_NETWORK_GRAPH 

A  geometric  representation  of  trafficability  over  terrain  that  can  be 
used  in  mobility  and  maneuver  analysis  applications. 

EDGE 

A  representation  of  contiguous  stretches  of  terrain  having  like  attrib¬ 
utes— especially  trafficability. 

NODE 

An  endpoint  of  a  graph  edge. 

FORCE 

A  group  of  ground  vehicles. 

Derivation  of  the  routes  depends  on  information  from  the  other  M-COP 
categories;  for  example,  slope  information  from  the  Terrain  category, 
minefield  placement  and  status  from  the  Obstacles  category,  precipitation 
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and  temperature  from  the  Weather  category,  positions  of  advantage  from 
the  Maneuver  Analysis  category,  presence  and  capabilities  of  enemy  forces 
from  the  Threat  Analysis  category,  and  mission  and  friendly  force  mobility 
assets  from  the  Forces  category.  The  BTRA  software  is  a  current  decision 
aid  doing  this  type  of  processing  to  generate  route  plans.  Because  the 
routes  are  products  of  such  processing,  there  is  a  clear  opportunity  for 
identifying  software  services  within  the  distributed  GIG  environment. 
Specification  of  M-COP  in  this  regard  will  include  not  only  the  products, 
but  should  also  characterize  the  processes  through  such  standards  as  the 
WSDL.  This  will  lead  follow-on  M-COP  specification  efforts  toward 
another  area  of  formalization,  namely  the  use  of  OWL-S  (Web  Ontology 
Language  for  Services)  to  provide  stronger  semantics  for  discovering  and 
orchestrating  Web  services  in  the  GIG  environment  (Alesso  and  Smith 
2005).  Egenhofer  (2002)  argues  for  the  development  of  a  geospatial 
language  for  making  requests  in  a  geospatial  web  environment.  The  same 
type  of  language  will  be  required  for  making  geospatial  requests  in  the  GIG 
environment. 

Forces 

The  Forces  category  describes  information  about  maneuver  and 
transportation  units,  and  individual  platform  locations  and  capabilities  as 
related  to  mobility  and  maneuver.  Because  representing  military  forces  is  a 
key  element  of  C4I  and  M&S  systems,  there  are  numerous  representations 
available  for  reuse  in  the  M-COP  data  model.  Clearly  applicable  are  the 
XML  Schema  representation  produced  by  the  Unit  Order  of  Battle  Data 
Access  Tool  (UOB  DAT)  (DMSO  1999)  and  the  XML  Schema  formalization 
of  scenario  data,  including  forces,  in  the  MSDL  (Surdu  et  al.  2005; 
Franceschini  et  al.  2004),  which  is  based  on  MIL-STD-2525B,  Common 
Warfighting  Symbology  (DISA  2005).  MSDL  is  a  leading  candidate  for 
use  in  the  M-COP,  as  it  is  currently  being  standardized  through  the 
Simulation  Interoperability  Standards  Organization  (SISO).  Moreover, 
MSDL  is  being  used  for  scenario  initialization  and  archival  storage  in  the 
OOS.  Taxonomies  of  military  forces  are  also  available  in  the  DOD  Meta¬ 
data  Registry  and  Clearinghouse.  Early  efforts  to  create  more  formal 
ontologies  for  military  unit  behaviors  are  described  in  Lacy  and  Henninger 
(2003)  and  for  other  military  M&S  purposes  in  Lacy  and  Gerber  (2004). 

The  stakeholders’  analysis  identified  the  following  characteristics  of  the 
Forces  category  as  being  important  to  mobility  planning  (Blais  et  al. 
2005b): 
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•  Enemy  forces: 

o  Disposition, 
o  Location, 
o  Size, 
o  Orientation, 
o  Capabilities, 
o  Weapon  types, 
o  Center  of  gravity, 
o  Asymmetric  or  symmetric? 
o  Information  requirements, 
o  Tactics,  Techniques,  and  Procedures  (TTP). 
o  Known  locations  with  date  time  group, 
o  Location  of  last  contacts  and  type  weapons  systems,  etc. 
o  Threat, 
o  Composition. 

o  Lire  support  assets  in  the  area, 
o  Historical  data  on  recent  activity  and  areas  to  avoid, 
o  Pattern  analysis  of  attacks  over  time. 

o  Need  additional  information  on  enemy  forces— Intent,  Capa¬ 
bility,  Identification. 

o  Movement— may  need  to  know  when  the  enemy  may  reach  a 
certain  location. 

o  Lields  of  fire  from  suspected  enemy  forces, 
o  Recent  mortar  activity  and  Observation  Post  (OP)  locations, 
o  Threat  courses  of  action. 

o  Avenues  of  approach  available  to  enemy  forces  but  not  to 
friendly  forces. 

o  Recent  operations  in  the  area, 
o  Historical  data  on  IED  attacks  or  ambushes. 

•  Lriendly  forces 

o  Disposition. 

o  Assets:  Vehicle  characteristics, 
o  Lire  support. 

o  Lriendly  Lorces  Information  Requirements  (LLIR). 
o  Information  requirements, 
o  Observer  locations. 

o  Lire  support-counter  battery  assets-range  fans, 
o  Location  of  all  friendly  forces, 
o  Lorce  structure. 

o  Battalion  (BN)  needs  down  to  squad  location, 
o  Location  of  all  Combat  Service  Support  (CSS)  and  Combat 
Support  (CS)  assets, 
o  Status  of  forces: 

■  In  urban  operations,  battalions  will  track  down  to 
platoon  slants,  individual  and  section  (two-vehicle) 
status,  which  could  also  include  infantry  squads  in 
nearby  operation. 


■  Brigades  will  usually  want  company  slants  as  well  (as 
opposed  to  red/amber /green  reports). 

o  Location  of  friendly  bases  with  contact  information  (call 
sign,  frequency,  etc.). 

o  Sectors,  battlespace,  retrans  lines,  medical  evacuation 

(MEDEVAC)  frequencies  and  units,  etc.,  over  long  distances: 

■  Possible  congestion,  choke  points. 

■  Timing  of  force  movements. 

o  Any  air-to-ground  attacks  in  area  of  operations  (i.e.,  Joint 
Direct  Attack  Munitions  [JDAMs],  etc)— heads  up  for 
unexploded  ordnance  (UXO). 
o  Recent  operations  in  this  area, 
o  Force  locations, 
o  Center  of  gravity, 
o  Communications  footprint. 

o  Available  engineer  mission  packages  (e.g.,  breaching  assets 
available,  countermine,  bridging), 
o  Unit  experience  in  the  environment  (AO  awareness), 
o  State  of  training, 
o  Maintenance  readiness  level. 

o  Mission,  tasks,  and  purposes  for  ongoing  operations: 

■  Offense-Defense. 

■  Flanking  movement,  movement  to  contact,  defense  in 
depth,  mobile  defense,  reserve,  etc. 

o  Logistics  status  (fuel  capacity  and  sustainment), 
o  Fatigue. 

o  Food  and  water  status. 

o  MEDEVAC— location  of  nearest  medical  facilities, 
o  Known  times  of  CSS/CS  convoys  in  area  of  operations  and 
when  US/Coalition  soft  targets  will  be  present  in  the  area  of 
operations. 

o  Update  on  left/right  adjacent  unit  activities  (could  indicate 
forces  coming  into  the  area  of  operations). 

Non-military  forces: 

o  Refugees  and  local  community, 
o  Displaced  civilians, 
o  Non-governmental  organizations, 
o  Private  volunteer  organizations, 
o  Local  populace  considerations, 
o  Local  populace  disposition  towards  friendly  forces, 
o  Recent  significant  interactions  and  incidents  between 
friendly  forces  and  local  populace, 
o  Traffic  control. 

o  Civilian  neutral  elements’  disposition  (tendencies  and  trends 
of  local  populace), 
o  Urban  traffic  patterns, 
o  Cultural  norms  in  traffic  flows. 
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o  Local  gasoline  situation, 
o  Types  of  local  traffic. 

After  eliminating  duplicate  information  and  consolidating  related 
information,  the  following  organization  of  data  results  for  the  Forces 
category  of  the  M-COP  data  model: 

•  FORCE_DISPOSITION  (military/para-military,  any  side): 
o  Identity, 
o  Location, 
o  Formation, 
o  Formation  spacing, 
o  Orientation, 
o  Center  of  gravity, 
o  Fields  of  fire, 
o  Mission/task/purpose, 
o  Movement: 

■  Direction. 

■  Speed. 

■  Plans  (timing,  locations), 
o  Affiliation. 

o  Communications  footprint, 
o  Equipment: 

■  Nomenclature. 

■  Type  of  equipment. 

■  Maintenance  readiness  level. 

■  Weapons:  Fire  support  assets. 

■  Vehicles: 

•  Vehicle  status. 

•  Mobility  characteristics, 
o  Personnel: 

■  Quantity. 

■  Military  occupation  codes. 

■  Experience  in  the  area  of  operations. 

■  State  of  training. 

■  Fatigue, 
o  Supplies: 

■  Fuel. 

■  Food. 

■  Water. 

o  Capability:  TTPs. 
o  Support: 

■  Engineering  (e.g.,  available  mission  packages  for 
breaching,  countermine,  bridging). 

-  CSS. 

•  CS. 
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■  Fire. 

■  Air. 

■  Intelligence/reconnaissance. 

■  MEDEVAC  locations,  frequencies. 

o  Information  requirements:  Observer  locations, 
o  Force  structure  (command/ subordinate  relationships), 
o  Bases: 

■  Identification. 

■  Location. 

■  Affiliation, 
o  Control  measures: 

■  Unit  boundaries. 

■  Adjacent  units’  dispositions. 

Thus,  the  disposition  of  a  force  consists  of  its  physical  state  on  the  battle¬ 
field  and  its  historical  and  planned  activities,  including  what  it  knows 
about  other  forces’  dispositions.  Note  that  the  concept  of  affiliation  or  side 
is  relative  and  not  necessarily  symmetrical.  Also  note  that  a  particular  side, 
say  Blue,  needs  to  know  its  own  movement  capabilities  as  well  as  those  of 
other  sides  (including  other  Blue  units)  to  project  the  state  of  the  battle- 
space  over  time  to  determine  the  potential  for  certain  “other-side”  move¬ 
ments  to  adversely  affect  own-side  planned  movements. 

Threat-specific  information  includes  the  following  historical  data: 

•  Location  of  last  contacts. 

•  Disposition  over  time  (where  “disposition”  includes  the  various 
data  identified  above  under  FORCE_DISPOSITION). 

•  Attacks  over  time. 

•  Enemy  activities  (recent  operations)  over  time. 

•  Mortar  activity  OP  locations. 

•  IED  attacks  or  ambushes. 

These  data  provide  a  basis  for  estimating  or  predicting  current  or  future 
capabilities  of  the  enemy  force  to  disrupt  or  impede  own-side  ability  to 
maneuver.  This  information  would  be  accumulated  from  intelligence 
reports,  contact  reports,  and  other  sources.  The  record  of  enemy  activities 
becomes  the  raw  material  for  performing  threat  analysis,  together  with 
FORCE_DISPOSITION  data. 

Some  of  the  information  dealing  with  enemy  forces  allocated  from  the 
stakeholders’  analysis  to  the  Forces  category  of  the  M-COP  data  model 
actually  reflects  inferences  that  can  be  made  based  on  the  above  informa- 
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tion,  and,  therefore,  make  more  sense  being  part  of  the  Threat  Analysis 
category  (next  section). 

Non-military  forces  are  not  necessarily  organized  in  the  same  sense  as  the 
forces  described  above,  but  create  background  traffic  in  the  battlespace 
that  can  affect  the  ability  of  military  forces  to  maneuver.  The  following  set 
of  information  is  retained  from  the  earlier  list  produced  in  the  stake¬ 
holders’  analysis  of  local  population: 

•  Refugees  and  local  community. 

•  Displaced  civilians. 

•  Non-governmental  organizations. 

•  Private  volunteer  organizations. 

•  Local  populace  considerations. 

•  Local  populace  disposition  towards  friendly  forces. 

•  Recent  significant  interactions  and  incidents  between  friendly 
forces  and  local  populace. 

•  Traffic  control. 

•  Civilian  neutral  elements’  disposition  (tendencies  and  trends  of 
local  populace). 

•  Urban  traffic  patterns. 

•  Cultural  norms  in  traffic  flows. 

•  Local  gasoline  situation. 

•  Types  of  local  traffic. 

This  information  is  exclusive  to  civilians  as  they  participate  in  an  activity 
(or  avoid  an  activity)  that  affects  mobility,  that  activity  is  classified  within 
the  Forces  category.  For  instance,  if  a  villager  takes  down  warning  signs 
indicating  that  a  field  contains  mines,  they  are  acting  as  an  agent  and  are 
no  longer  solely  a  civilian.  Obviously,  this  can  lead  to  debate  about  what 
constitutes  participation  versus  normal  activity  that  may  affect  operations. 
The  entire  purpose  of  the  M-COP  ontology  is  to  assist  with  the  sharing  of 
information.  There  is  the  potential  for  significant  overlap  among  the  vari¬ 
ous  categories  in  the  ontology.  This  is  especially  true  with  regard  to  the 
civilian  category.  Therefore,  it  is  important  that  you  fully  understand  how 
we  are  defining  the  civilian  class.  Determining  which  category  “receives 
credit”  for  activities  is  not  as  relevant  as  making  sure  the  user  records  and 
labels  all  activities  and  objects  somewhere.  Thus,  in  ambiguous  situations, 
the  activity  or  object  will  go  in  a  non-civilian  category. 

The  following  characteristics  of  civilians  provide  additional  information  to 
identify  purely  civilian  effects  on  mobility.  They  consist  primarily  of 
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cultural  activities  such  as  holidays  and  religious  customs.  However,  as  the 
ontology  develops  over  time,  new  characteristics  are  sure  to  emerge. 

•  Religious: 

o  Customs  (eye  contact,  entering  holy  sites,  holidays,  etc.), 
o  Constraints  (roles  of  men/women,  clothing,  etc.), 
o  Distribution  by  denomination  or  sect  (e.g.,  1/3  Sect  A,  2/3 
Sect  B). 

o  “Holy  ground  or  sites”  (mosques,  burial  grounds, 
shrines/statues). 

•  Secular: 

o  Language  and  standards  (street  signs,  graffiti,  metric  vs. 
English). 

o  Secular  customs  (attitudes,  values,  etc.), 
o  Type  of  work  (industrial,  agricultural,  etc.), 
o  Local  laws  and  regulations  (drive  on  left  side  of  road,  size 
limitations  of  motor  vehicles,  etc.), 
o  Economic  factors. 

Table  8  provides  definitions  of  the  two  proposed  classes  for  the  Forces 
category  subclasses,  and  attributes  are  discussed  below. 


Table  8.  Forces  category  classes. 


Class 

Definition 

FORCE_DISPOSITION 

Information  about  the  identity,  affiliation,  spatial  characteristics, 
activities,  plans,  capabilities,  assets,  readiness,  and  structure  of 
an  organization  operating  in  the  battlespace. 

LOCAL_POPULATION 

Information  about  indigenous  people,  customs,  behaviors, 
activities,  and  laws  that  affect  ground  vehicle  mobility  in  an  area 
of  the  battlespace. 

While  Forces  data  can  identify  the  state  of  the  local  populace,  threat  analy¬ 
sis  computations  on  these  data  provide  edge  weights  for  route  finding 
algorithms  to  estimate  the  effects  on  ground  vehicle  mobility.  There  is  a 
clear  path  for  orchestrated  services  here,  where  a  request  to  a  service  for 
route  finding  spawns  a  request  to  a  service  to  perform  threat  analysis  (spe¬ 
cifically,  mobility  threat  analysis)  to  obtain  updated  weighting  of  factors 
characterizing  the  edges  of  the  maneuver  network.  The  Threat  Analysis 
service,  in  turn,  requests  M-COP  data  (Terrain,  Weather,  Obstacles, 

Forces,  etc.)  through  an  M-COP  data  service  that  is  aware  of  the  diverse 
sources  of  the  relevant  information. 

The  MSDL  identifies  information  needed  for  scenario  initialization, 
including  the  following  (SISO  2005): 
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•  Options:  Identify  how  task  organizations  are  specified  (entity  or  aggre¬ 
gate  based),  the  data  standards  being  used  by  the  scenario  (coordinate 
systems  and  associated  datum;  enumeration  standard  and  version)  and 
any  application-specific  options  that  have  been  created  by  the  Com¬ 
mand  and  Control  (C2)  planning  application  or  applications  that  cre¬ 
ated  the  scenario. 

•  Environment:  Absolute  scenario  time  (initial  time),  identification  of 
the  terrain  (data  source  and  terrain  boundaries),  synoptic  weather 
(temperature  range,  moonrise  and  set  times,  sunrise  and  set  times, 
nautical  twilight,  clouds/fog/haze  visibility  and  ceiling  information), 
and  METOC  graphics  (from  MIL-STD-2525B). 

•  Force  Structure:  Specifies  the  sides  of  the  battle  to  which  specific 
forces  are  aligned. 

•  Task  Organizations:  Identifies  units  and  equipment,  where  equipment 
generally  equates  to  entities  in  a  simulation  and  follows  MIL-STD- 
2525B  classification. 

•  Installations:  Identify  military  facilities. 

•  Overlays:  Provide  a  mechanism  for  linking  Tactical  Graphics  to  spe¬ 
cific  Overlays  or  Layers  to  be  placed  on  a  tactical  map  display.  Overlay 
types  include  Operations,  Fire  Support,  Modified  Combined  Obstacles, 
Intelligence,  Reconnaissance/Surveillance,  Obstacle,  Air  Defense, 

Army  Airspace  Command  and  Control  (A2C2),  and  User-Defined. 

•  Tactical  Graphics:  Define  control  measures  (by  referencing  particular 
Overlay  entries). 

•  Military  Operations  Other  Than  War  (MOOTW)  Graphics:  MOOTW 
symbol  modifiers  as  defined  in  MIL-STD-2525B. 

•  Treats:  Specify  non-military  (threat)  organizations,  including  charac¬ 
terizing  the  effects  of  threat -based  actions  and  activities. 

•  Plan:  Provide  descriptive  information  on  the  scenario  as  well  as 
executable  courses  of  action.  Information  includes  an  executive  sum¬ 
mary  of  the  Operations  Order  (OPORD),  scenario  objectives,  refer¬ 
ences  to  doctrine,  and  planning  documents.* 

While  the  MSDL  Environment  component  provides  information  that  is 

relevant  to  several  M-COP  data  categories,  we  are  interested  here  in  the 

components  that  carry  information  relevant  to  the  Forces  category  of  the 

M-COP.  The  MSDL  components  relevant  to  the  Forces  category  are  Plan, 

ForceStructure,  TaskOrganizations,  Installations,  Overlays, 


*  Expression  of  orders  will  use  the  companion  specification,  C-BML,  also  undergoing  standardization 
through  the  SISO  at  the  time  of  this  writing. 
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TacticalGraphics,  MOOTWGraphics  and  Threats.  Table  9  associates  the 
M-COP  Forces  category  data  requirements  for  the  class 
FORCE_DISPOSITION  from  the  above  synthesis  with  XML  elements  and 
attributes  from  the  MSDL  structure  to  show  what  parts  of  the  M-COP 
Forces  model  are  covered  in  M-COP  and  what  parts  are  not.  In  Table  9,  the 
location  of  the  information  in  the  MSDL  structure  is  provided  in  XPath 
notation  (W3C  1999)  where  feasible.  Refer  to  the  MSDL  XML  Schema 
files*  for  more  detail. 


Table  9.  Association  of  the  M-COP  Forces  category  with  MSDL  data  structures. 


M-COP  Forces  Classes  and 
Attributes 

MSDL  Data  Structure 

Force_Disposition+ 

Primarily  found  in  /MilitaryScenario/TaskOrganizations  but  also  in  other  parts  of 
the  MSDL  data  structure  as  will  be  seen  below. 

-Identity 

/MilitaryScenario/TaskOrganizations/Units/Unit/Name  (and/or 
.../Unit/ObjectFlandle  providing  the  Universal  Unique  Identifier  [UUID]  of  the  unit). 

-Location 

/MilitaryScenario/TaskOrganizations/Units/Unit/Location  (in  MGRS,  UTM,  GDC, 
or  GCC). 

-Formation 

/MilitaryScenario/TaskOrganizations/Units/Unit/Position/Formation 
(indicating  how  subordinate  units  an  echelon  below  will  be  positioned;  this 
information  is  provided  at  the  Equipmentltem  level  as  well). 

-Formation  spacing 

/MilitaryScenario/TaskOrganizations/Units/Unit/Position/Spacing. 

-Orientation 

/MilitaryScenario/TaskOrganizations/Units/Unit/Position/Orientation. 

-Center  of  gravity 

NOT  PROVIDED— can  be  proposed  as  an  extension  to  the  MSDL  specification  of 
Unit,  UnitLocation,  or  UnitPosition. 

-Fields  of  fire 

NOT  PROVIDED— can  be  proposed  as  an  extension  to  the  MSDL 
/MilitaryScenario/TacticalGraphics  constructs. 

-Plan 

/MilitaryScenario/Plan  consists  of  Objectives  and  Courses  of  Action. 

-Purpose 

/MilitaryScenario/Plan/Course  of  Action  (COAJ/COA  Purpose. 

-Activity 

/MilitaryScenario/Plan/COA/ActivityType  (note:  C2IEDM  Action  type). 

-Task 

/MilitaryScenario/Plan/COA/COAPhases/COAPhase/PhaseEvents/Event/ 
UnitActivities/Activity/ActivityData/Task/Enumeration,  where  the  enumeration  is 
taken  from  the  Army  Universal  Task  List. 

-Movement 

A  Movement  operation  is  one  of  the  values  of  .../COA/COAPurpose.  Therefore,  a 
movement  task  is  identified  in  the  Plan  structure  described  above. 

-Direction 

/MilitaryScenario/TaskOrganizations/Units/Unit/DirectionOfMovement 

-Speed 

NOT  PROVIDED— as  an  initialization  tool,  MSDL  considers  all  forces  to  be 
stationary;  movement  order  processing  is  performed  by  the  using  simulation  or 

BC  application). 

*  Currently  available  through  the  SISO  MSDL  Product  Development  Group.  See  http://www.sisostds.org. 
t  Dashes  and  indentation  indicate  the  hierarchical  structure  of  the  data. 
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Table  9  (cont.).  Association  of  the  M-COP  Forces  category  with  MSDL  data  structures. 


M-COP  Forces  Classes  and 
Attributes 

MSDL  Data  Structure 

-Movement  Plans 

See  above,  described  as  one  of  the  types  of  activity  that  can  be  specified  in  a 

Plan. 

-Affiliation 

/MilitaryScenario/TaskOrganizations/Units/Unit/ForceRelation/ 

ForceSideHandle 

-Communications  footprint 

MSDL  provides  the  capability  to  describe  communications  connectivity  (refer  to 
/MilitaryScenario/TaskOrganizations/Units/Unit/  CommunicationNetlnstances 
and  /MilitaryScenario/TaskOrganizations/Equipment/Equipmentltem/ 
CommunicationNetReferences).  The  Communications  Footprint  will  need  to  be 
computed  by  a  tool/service  accepting  the  communications  equipment,  locations, 
terrain,  and  environment  data,  at  a  desired  level  of  resolution. 

-Equipment 

/MilitaryScenario/TaskOrganizations/Equipment/Equipmentltem. 

-Nomenclature 

/MilitaryScenario/TaskOrganizations/Equipment/Equipmentltem/Name  (and/or 
.../Equipmentltem/ObjectHandle  providing  the  UUID  of  the  item  of  equipment). 

-Type  of  equipment 

/MilitaryScenario/TaskOrganizations/Equipment/Equipmentltem/  Enumeration. 

-Quantity 

/MilitaryScenario/Plan/TaskOrganizations/Equipment/Equipmentltem/ 

EquipmentSymbolModifiers/Quantity. 

-Maintenance  readiness 

level 

NOT  PROVIDED— can  be  proposed  as  an  extension  to  the  MSDL  specification, 
possibly  for  the  .../Equipmentltem/EquipmentSymbolModifiers/CombatEffective- 
ness  entry. 

-Weapons 

Classification  of  an  item  of  equipment  as  a  weapon  or  vehicle  needs  to  be 
determined  from  the  Enumeration  value  and  its  mobility  characteristics. 

—Fire  Support  Assets 

(as  above). 

-Vehicles 

(as  above). 

—Mobility 

characteristics 

(Refer  to  the  NRMM/STNDMob  discussion  in  the  text). 

-Personnel 

NOT  PROVIDED— should  be  added  as  extensions  to  Equipment  Items  in  the  MSDL 
specification  (“Diver”  is  the  only  EquipmentEnumeration  value  of  associated  with 
a  human!). 

-Quantity 

/MilitaryScenario/Plan/TaskOrganizations/Equipment/Equipmentltem/ 

EquipmentSymbolModifiers/Quantity. 

-Military  Occupation 

Specialties 

NOT  PROVIDED— can  be  proposed  as  an  extension  to  the  MSDL  specification  of 
Equipmentltem  (consider  the  EnumerationSubType  entry). 

-Experience  in  the  area  of 
operations 

NOT  PROVIDED— can  be  proposed  as  an  extension  to  the  MSDL  specification. 

-State  of  training 

NOT  PROVIDED— can  be  proposed  as  an  extension  to  the  MSDL  specification. 

-Fatigue 

NOT  PROVIDED— MSDL  does  not  provide  an  initial  condition  of  the  personnel  for 
initialization  of  simulation  or  BC  systems. 

-Supplies 

Supplies  such  as  fuel,  food,  and  water  (and  ammunition/ordnance)  are  not 
provided  explicitly;  i.e.,  there  is  no  enumerated  value  for  EquipmentEnumeration 
identifying  these  types  of  Equipmentltem. 

-Capability  (including  TTPs  and 
mission  packages) 

NOT  PROVIDED— but  one  can  imagine  populating  a  MilitaryScenario  document 
with  identification  of  forces  and  courses  of  action  down  to  individual  tasks  that 
could  be  interpreted  as  identification  of  tasks  suitable  to  the  identified  Unit. 
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Table  9  (cont.).  Association  of  the  M-COP  Forces  category  with  MSDL  data  structures. 


M-COP  Forces  Classes  and 
Attributes 

MSDL  Data  Structure 

-Support 

/MilitaryScenario/TaskOrganizations/Units/Unit/SupportRelations 

This  is  identified  from  the  perspective  of  the  unit  providing  support— see 
/MilitaryScenario/TaskOrganizations/Units/Unit/SupportRelations.  The 
enumerations  for  SupportType  are  currently  General  Support  (GS),  Direct  Support 
(DS),  Regimental  Support  (RS),  General  Support— Reinforcing  (GS-R),  and  NONE. 
Types  of  support  of  interest  to  M-COP— Engineering,  Combat  Service  Support, 
Combat  Support,  Fire,  Air,  Intel/Recon,  and  MEDEVAC— an  be  inferred  from  the 
type  of  unit  (from  .../Unit/Enumeration). 

-Information  requirements 
(observer  locations) 

Not  directly  provided,  but  could  possibly  be  inferred  from  .../Unit/Position 
information  regarding  Formation  (especially  down  to  the  placement  of  each 
individual  item  of  Equipment)  or  from  supporting  Intel/Recon  forces. 

-Force  structure 

Can  be  generated  from  the  collection  of  entries  for  each  unit  in 
/MilitaryScenario/TaskOrganizations/Units/Unit/ForceRelation/ 

CommandRelation. 

-Bases 

/MilitaryScenario/lnstallations. 

-Identification 

/MilitaryScenario/lnstallations/lnstallation/Name  (and/or 
.../Installation/ObjectHandle  providing  the  UUID  of  the  installation). 

-Location 

/MilitaryScenario/lnstallations/lnstallation/Location  (also  .../Orientation). 

-Affiliation 

/MilitaryScenario/lnstallations/lnstallation/ForceSideHandle. 

-Control  measures 

Described  in  /MilitaryScenario/TacticalGraphics,  referencing  specific  Overlays 
defined  in  /MilitaryScenario/Overlays.  Types  of  Overlays  currently  identified  in 
MSDL  include  Operations,  Fire  Support,  Modified  Combined  Obstacles,  Intel, 
Recon/Surveillance,  Obstacle,  Air  Defense,  Logistics,  Army  Airspace  Command 
and  Control  (A2C2),  and  User-Defined.  Location  of  control  measures  is  described 
by  a  set  of  anchor  points  (.../TacticalGraphics/TacticalGraphic/AnchorPoints). 

-Unit  boundaries 

Each  TacticalGraphic  may  reference  a  MIL-STD-2525B  Symbol  Class,  one  of 
which  is  .../TacticalGraphic/MILSTD2525BSymbolClass/BoundarySymbol- 
Modifiers  with  indication  of  Echelon  or  Hostile  aspects  of  the  boundary. 

-Adjacent  units’ 
dispositions 

Once  adjacent  units  are  identified,  their  disposition  is  provided  through  the  data 
identified  above. 

One  of  the  XML  Schema  files  making  up  MSDL  is  an  enumeration  of 
equipment  types  for  items  that  can  be  possessed  by  units  in  the 
ForceStructure  component  (XML  simple  type  EquipmentEnumeration). 
The  EquipmentEnumeration  data  type  uses  a  unique  code  for  each  item  of 
equipment,  with  an  annotation  describing  the  type  of  equipment  so  desig¬ 
nated.  The  annotations  identify  types,  without  going  down  to  the  level  of 
individual  equipment  nomenclatures.  For  example,  consider  the  XML 
fragment  from  the  enumeration  identifying  the  Tank  subclass  of  equip¬ 
ment  (“1.X.3.2.2.1.1”  in  the  MSDL  equipment  taxonomy)  in  Figure  5. 

An  initial  reaction  is  to  wonder  why  the  list  does  not  go  down  to  individual 
nomenclatures,  such  as  the  M1A1  Main  Battle  Tank,  but  there  is  an  addi¬ 
tional  EnumerationSubType  that  may  be  intended  for  that  purpose.  While 
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<xs :  enumeration  value= "  i.X.  3 . 2. 2 . 1 . 1 "  > 

<xs:  annotation  > 

<xs :  documentation  >  T  anlc<  /xs :  documentation  > 

<  /xs :  annotation  > 

<  /xs :  enumeration  > 

<xs:enumeration  value="i.X-3.2. 2.1.1. i"> 

<xs:  annotation  > 

<  xs:  documentation  >  Light  tank< /xs :  documentation  > 

<  /xs :  annotation  > 

</xs:enumeration  > 

<xs:  enumeration  value=' '1.X.3.2.2.1.1.1.1' "> 

<xs:  annotation  > 

<xs :  documentatio  n  s  Recover,-  light  tank</xs:docmnentation> 

<  /xs :  annotation  > 

<  /xs:enumeration  > 

<xs:enumeration  vralue="i.X.3.2.2.i.i.2’'> 

<xs:annotation> 

<xs:documentation>Medium  tank</xs:documentation> 

< /xs :  annotation  > 

<  /xs :  enumeration  > 

<xs  remuneration  value="i.X.3.2.2.i.i.2.i"> 

<xs:annotation> 

<xs:documentation>Recoverv  medium  tank<  /xs:  documentation  > 

<  /xs:  annotation  > 

<  /xs :  enumeration  > 

<xs:enumeration  value="i.X.3.2.2.i.i.3"> 

<xs:annotation> 

<xs :  documentation  >  Heavy  tank<  /xs :  documentation  > 

<  /xs :  annotation  > 

</xs :  enumeration  > 

<xs:enumeration  value='  i.X.3.2.2.i.i.3.i"> 

<xs:  annotation  > 

<xs:documentation>Recovery  heavy  tank</xs:documentation> 

<  /xs :  annotation  > 

xs  remuneration 

Figure  5.  XML  fragment  of  MSDL  equipment  taxonomy. 


the  MSDL  representation  provides  a  path  for  sharing  scenario  data  across 
various  applications,  it  is  different  from  saying  MSDL  provides  data  inter¬ 
change.  Additional  logic  may  be  needed  on  the  source  or  destination  side 
(or  both)  to  translate  the  MSDL  classification  of  an  item  of  Equipment  into 
the  classification  needed  in  a  particular  application.  Dealing  with 
enumeration  lists  has  been  a  long-standing  problem  in  the  BC  and  M&S 
domains.  One  of  the  most  extensive  lists  for  military  systems  can  be  found 
in  the  Distributed  Interactive  Simulation  (DIS)  standard  (IEEE  1995). 

The  Standard  Mobility  (STNDMob)  API  is  a  candidate  for  implementation 
as  a  service  on  the  GIG  to  provide  vehicle  speeds  to  vehicle  routing  ser¬ 
vices  and  planning  aids.  The  NRMM  is  the  Army  Modeling  and  Simulation 
Office  standard  for  single  vehicle  ground  movement  representation 
(Ahlvin  and  Haley  1992).  A  STNDMob  API  has  been  developed  based  on 
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the  NRMM  to  incorporate  terrain-limited  vehicle  speed  determinations 
into  M&S  systems  (Baylot  et  al.  2005).  While  the  ultimate  goal  of  the  work 
is  to  create  Aggregate,  Tactical/Entity,  and  Engineering  level  resolution 
models,  work  to  date  has  provided  two  levels  of  resolution  for  Tacti¬ 
cal/Entity  application:  1)  a  low  resolution  model  based  on  preprocessed 
speed  predictions  from  NRMM  and  some  limited  sensitivity  to  variations 
in  terrain  characteristics,  and  2)  a  medium  resolution  model  based  on  pre- 
processed  tractive  force  relationships  and  the  forces  limiting  movement  in 
the  environment. 

This  prior  work  fully  meets  the  requirements  for  M-COP  data  with  regard 
to  vehicle  mobility  characteristics.  An  extensive  XML  Schema  representa¬ 
tion  is  available  for  general  use,  in  addition  to  the  STNDMob  API  software 
implementation,  XML  Schema,  and  XML  data  files.  Version  2.0  of  the 
NRMM  Vehicle  XML  Schema  is  provided  in  Appendix  F  and  Appendix  G 
contains  an  example  XML  file  storing  NRMM  vehicle  data  for  the  M1A1 
Abrams  tank  in  accordance  with  the  schema. 

Threat  Analysis 

The  Threat  Analysis  category  includes  the  locations,  capabilities,  and  other 
information  (potential  actions)  relating  to  things  that  can  threaten  a  mis¬ 
sion.  Note  that  this  can  include,  in  addition  to  enemy  forces,  local  popula¬ 
tion  and  cultural  effects  as  they  affect  friendly  maneuver  (Melby  and  Glenn 
2002).  As  discussed  earlier  concerning  the  Maneuver  Analysis  category, 
the  IPB  process  offers  a  rich  resource  for  framing  the  Threat  Analysis  cate¬ 
gory.  Steps  three  and  four  of  the  traditional  IPB  process  are  evaluate  the 
threat  and  determine  threat  courses  of  action,  respectively  (FM  34-130, 
HQDA 1994)  and  we  used  this  to  differentiate  among  elements  included  in 
the  Maneuver  Analysis  category  versus  the  Threat  Analysis  category.  Like¬ 
wise,  there  are  attributes  that  were  deliberately  included  in  the  Forces 
category  that  support  the  Threat  Analysis  category.  For  our  analysis,  we 
are  specifically  concerned  with  aspects  of  these  that  pertain  to  mobility 
and  maneuver. 

In  considering  concepts  for  the  Threat  Analysis  category  related  to 
evaluating  the  threat  and  determining  possible  courses  of  action  they 
might  adopt,  our  focus  was  to  consider  what  actions  other  forces  (military 
or  non-military)  could  take  to  undermine  conditions  that  must  hold  for  the 
movement  plan  to  be  successful.  While  an  enemy  cannot  influence  the 
weather  to  create  poor  road  conditions,  he  can  possibly  attack  a  dam  that 
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would  flood  an  area  and  have  the  same  effect.  Or,  if  the  movement 
depends  highly  on  fuel  reserves,  an  insurgent  IED  attack  on  the  fuel  trans¬ 
port  could  create  a  condition  for  mission  failure.  The  challenge  for  the 
ontology  design  is  to  be  able  to  express  these  often  intertwined  cause- 
effect  relationships  matching  enemy  capabilities  to  create  certain  effects  to 
underlying  conditions  or  assumptions  that  must  hold  to  achieve  mission 
success.  This  is  an  area  where  the  M-COP  work  can  complement  BML 
ontology  development  work  dealing  with  expression  of  plans  and  orders 
(Galvin  et  al.  2005). 

The  stakeholders’  analysis  categorized  a  number  of  effects  under  the 
Forces  category  that  reflect  threat  information  that  is  inferred  from  Forces 
data,  including  Threat  Analysis: 

•  Enemy  threat. 

•  Enemy  intent. 

•  Asymmetric  or  symmetric  threat. 

•  Pattern  analysis  of  attacks  over  time. 

•  Areas  to  avoid  because  of  history  of  enemy  activities. 

•  Courses  of  action. 

•  Avenues  of  approach  available  to  enemy  forces  but  not  to  friendly 
forces. 

•  Possible  congestion  or  choke  points. 

Some  of  these  items  are  represented  in  the  Maneuver  Analysis  category  as 
discussed  previously  (e.g.,  avenues  of  approach,  choke  points).  While  some 
of  these  concepts  could  have  been  placed  in  the  Forces  category,  they  were 
included  in  Threat  Analysis  because  we  chose  to  have  Forces  describe  the 
static  and  dynamic  characteristics  of  forces  in  the  battlespace,  while  the 
above  set  of  inferences  identify  logical  consequences  of  the  presence  and 
capabilities  of  those  forces  on  ground  vehicle  mobility. 

Classes  pertaining  to  threat  analysis  not  already  represented  in  the 
Maneuver  Analysis  or  Forces  categories  are  given  in  Table  10.  The  two 
classes  represent  course  of  action,  as  denoted  by  the  stakeholder  and 
above,  and  situation  template.  Both  of  these  are  produced  during  the 
analysis.  They  are  composed  of  several  elements  and  involve  the  perceived 
mission  and  intent  of  the  threat. 
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Table  10.  Association  of  the  M-COP  Threat  Analysis  category  with  MSDL  data  structures. 


Class 

Definition 

Appendix  H 

THREAT_COURSE_OF_ACTION 

“A  possible  plan  open  to  an  individual  or  commander 
that  would  accomplish  or  is  related  to  accomplishment  of 
the  mission.  A  COA  is  initially  stated  in  broad  terms  with 
the  details  determined  during  staff  wargaming.  To 
develop  COAs,  the  staff  must  focus  on  key  information 
and  intelligence  necessary  to  make  decisions.  COAs 
include  five  elements:  WHAT  (the  type  of  operation), 

WHEN  (the  time  the  action  will  begin),  WHERE 
(boundaries,  axis,  etc.),  HOW  (the  use  of  assets),  and 

WHY  (the  purpose  or  desired  end  state).”—  FM  34-130 

Table  HI 

SITUATION_TEM  PLATE 

"(DOD)  Depiction  of  assumed  adversary  dispositions, 
based  on  adversary  doctrine  and  the  effects  of  the 
battlespace  if  the  adversary  should  adopt  a  particular 
course  of  action.  In  effect,  the  situation  templates  are 
the  doctrinal  templates  depicting  a  particular  operation 
modified  to  account  for  the  effects  of  the  battlespace 
environment  and  the  adversary’s  current  situation 
(training  and  experience  levels,  logistic  status,  losses, 
dispositions).  Normally,  the  situation  template  depicts 
adversary  units  two  levels  of  command  below  the  friendly 
force,  as  well  as  the  expected  locations  of  high-value 
targets.  Situation  templates  use  time-phase  lines  to 
indicate  movement  of  forces  and  the  expected  flow  of  the 
operation.  Usually  the  situation  template  depicts  a 
critical  point  in  the  course  of  action.  Situation  templates 
are  one  part  of  an  adversary  course  of  action  model. 
Models  may  contain  more  than  one  situation  template.”— 
FM  101-5-1 

Table  H2 

Of  note,  MSDL  has  an  interesting  portion  of  its  structure  dealing  specifi¬ 
cally  with  non-military  threat  organizations  and  threats  to  operations  from 
environmental  events.  Figure  6  shows  the  top-level  XML  Schema  structure 
of  this  portion  of  the  MSDL  data  model.  The  ThreatActivity  element  pro¬ 
vides  a  characterization  of  the  threat  activity  or  course  of  action  as 
MOST_DANGEROUS,  MOST_LIKELY,  or  OTHER,  and  provided 
information  on  the  intensity  (SEVERE,  HIGH,  MEDIUM,  LOW, 
UNKNOWN),  trend  of  intensity  (INCREASING,  DECREASING,  STEADY, 
UNKNOWN),  effect  (e.g.,  BURN,  CAPTURE_KIDNAP,  DESTROY, 

FO RCE_TO_WITHD RAW,  IDENTIFY,  ILLUMINATE,  KILL,  and  others), 
and  timing  (DAYTIME,  MORNING,  EVENING,  NIGHTTIME, 

TWILIGHT,  ANYTIME,  UNKNOWN)  of  the  event.  The  data  structure  also 
allows  identification  of  subsequent  activities  that  can  follow  the  threat 
activity. 


ERDC  TR-07-4 


55 


^ObjectHandle 

The  Universe!  Unique 
Identifier  UUID  of  an  object 


IHl  *1 

Name 

Unabbreviated  designation. 


Threat  [fi - TijpEl- 


^ThreatType 

The  type  of  threat  as  a 
non-military  organization,  or 
environmental  threat. 


A  specific  threat 
organization. 


”  Characterization 

Characterization  of  the  theat 
as  Most  Likely,  Most 
Dangerous,  or  Other. 


1^- 

--|“ForceSideHandle  I 

_ i 

A  UUID  reference  to  the 
Force  or  Side  information. 


Typical  Activities  [+] 

The  identification  a  typical 
threat  activity  and 
corresponding  effects. 


Figure  6.  MSDL  Threat  Data  Model  (SISO  2005). 


Clearly,  more  information  is  needed  for  such  data  to  be  useful  to  the  M- 
COP.  For  one,  the  threat  activity  needs  to  more  clearly  specify  the  targeted 
object  (e.g.,  a  bridge)  or  capability  (e.g.,  road  movement  by  creating  traffic 
problems)  to  determine  possible  effects  on  ground  vehicle  mobility.  Also, 
the  purpose  of  this  data  structure  in  MSDL  appears  to  be  for  identifying 
events  that  can  be  injected  into  a  simulation  or  C4I  system  (i.e.,  during  a 
training  exercise)  by  software  or  by  a  control  team  to  create  situations  that 
will  create  specific  training  opportunities.  Serving  both  live  BC  systems 
and  M&S  systems,  M-COP  requires  information  of  this  nature  dynamically 
from  events  occurring  in  the  battlespace  and  registered  into  the  informa¬ 
tion  system  (e.g.,  through  tactical  or  intelligence  reports)  for  access  and 
retrieval  by  M-COP  implementations.  Such  information  can  include 
intelligence  that  indicates  such  threat  activities  that  may  occur  in  the 
future  and  need  to  be  taken  into  account  (as  appropriate  to  the  quality  and 
reliability  of  the  information)  in  movement  planning. 


Utilities 

The  Utilities  category  consists  of  classes  and  attributes  for  metadata  and 
data  model  representations  or  geometry.  The  Utility  category  classes 
developed  for  the  M-COP  are  shown  in  Table  11.  Complete  descriptions  of 
the  attributes  of  these  classes  are  included  in  Table  11. 
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Table  11.  Utilities  category  classes. 


Classes 

Definition 

DATA_QUALITY 

Descriptions  of  the  quality  of  the  data. 

FEATURE 

Representation  of  real  world  features. 

FEATU  R  E_TO  PO  LOGY 

Information  on  connectivity  and  adjacency  information  in 
an  environment. 

FORMAT 

Physical  attributes  of  the  asset  including  file  size,  bit  rate, 
storage  media. 

GEOMETRY 

Spatial  representation  of  an  object. 

LOCATION 

Information  about  the  location  of  another  object  relative  to 
this  object. 

RESOURCE 

Maintenance,  administration,  and  pedigree  of  the  data  set. 

SECURITY_CLASSIFICATION 

Security  level  assigned  to  national  security  information. 

SOURCE 

References  to  assets  or  resources  from  which  the  tagged 
data  asset  is  derived. 

SUMMARY_CONTENT 

Concepts  and  topics. 

TIME 

Time/date,  time/date  formats. 

USAGE 

Information  on  the  usage  of  certain  objects. 

Metadata  is  defined  as  data  about  data.  As  the  M-COP  is  more  of  a  special¬ 
ized  collection  of  information  and  services  from  the  distributed  data  envi¬ 
ronment  (i.e.,  it  can  be  thought  of  as  a  virtual  distributed  database  on  the 
GIG)  rather  than  a  specific  physical  data  structure  on  the  network,  the 
individual  components  making  up  the  M-COP  will  be  discoverable  in  their 
own  right  through  adherence  to  the  DOD  Discovery  Metadata  Specifica¬ 
tion  (DDMS)  (DOD  2005).  Therefore,  the  metadata  associated  with  M- 
COP  information  components  must,  at  a  minimum,  adhere  to  the  DDMS. 
Metadata  elements  from  EDCS  and  JMCDM  are  also  included  in  Table  11. 

The  “obligation”  requirement  (DOD  2005)  of  each  class  is  determined  by 
the  attributes  contained  within  the  class.  Several  of  the  metadata  elements 
have  a  ‘Mandatory’  obligation,  meaning  the  class  or  attribute  must  be  sup¬ 
plied.  A  ‘Mandatory  Unless  Not  Applicable’  obligation  means  that  the  class 
or  attribute  must  be  supplied  if  there  is  coverage  information  related  to  the 
data  asset.  A  ‘Conditional’  obligation  means  that  the  usage  of  an  element 
depends  upon  a  particular  condition.  An  ‘Optional’  obligation  means  that 
an  element  can  be  supplied,  but  is  not  required. 

The  M-COP  classes  FEATURE  and  FEATURE_TOPOLOGY,  and  GEOMETRY 
provide  attributes  for  the  M-COP  representation  in  a  real-world  environment. 
The  class  GEOMETRY  specifies  the  data  necessary  to  produce  both  visual 
and  non-visual  representations  of  environments.  The  attributes  include 
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Point,  Line,  and  Polygon.  The  class  FEATURE_TOPOLOGY  provides  con¬ 
nectivity  and  adjacency  information  in  an  environment.  To  represent  a 
road  as  a  “thing”  with  associated  topological  information,  a  data  provider 
can  represent  it  as  a  FEATURE,  which  by  definition  has  associated 
topological  information.  A  data  provider  might  choose  to  represent  the 
road  in  this  example  as  a  Linear_Feature,  where  each  segment  of  the  road 
is  a  separate  FEATURE_TOPOLOGY  instance,  in  this  case  a 
Feature_Edge.  The  topology  relationships  assist  by  providing  explicit 
information,  instead  of  performing  calculations  to  derive  the  information. 

Figure  7  shows  a  partial  sample  XML  representation  of  the  geospatial 
coverage  and  bounding  geometry  obtained  from  the  DOD  XML  repository; 
note  the  reference  to  GML.* 


<  <ddms:geospatialCoverage> 
ddms:GeospatialExtent> 
ddms:geographiddentifier> 
ddms:name >Iraq  :/ddms:name> 

ddms:counbyCode  ddms:qualifier="http:/ / metadata.dod.mil/ mdr/ns/ExtStd/1.0/FIPS10-4-2.owl#IZ 

/> 

</ddms:geographicIdentifier> 

<! — 

This  boundingGecmetry  creates  a  box  around  Baghdad  using  the  WGS-84  Coordinate  Reference 
System.  The  "srsDimension"  attribute  indicates  the  length  of  coordinate  sequence  (the  number 
of  entries  in  the  list),  i.e.  the  number  of  components  in  the  tuple,  here  2.  The  "count” 
attribute  specifies  the  number  of  direct  positions  in  the  list,  here  5. 

—  > 

ddms:  boundingGeometry:* 
gml:  Polygon  > 
gml:exterior> 
gml:LinearRing> 

gmhposList  gml:srsName=  WGS84"  gml:srsDimension="2"  gml :count="5'  >34.0  44.0  33.0  44.0  33.0  45.0 
34.0  45.0  34.0  44.0</gml:posList> 

</gml :  LinearRing  > 

</gml:exterior> 

</gml:  Polygon:* 

</ddms:boundingGeometry> 

<  /ddms :  Geospatial  Extent:* 

<  /ddms :  geospatial  Coverage  > 

Figure  7.  Representation  of  geospatial  coverage  and  bounding  geometry  in  XML. 


*  GML— OpenGIS  Geography  Markup  Language— this  specification  provides  objects  for  describing 
geography,  including  features,  coordinate  reference  systems,  geometry,  topology,  time,  unit  of  measure, 
and  generalized  values.  The  Open  Geospatial  Consortium,  Inc  (OGC)  (http://www.opengeospatial.org/)  is 
an  international,  non-profit,  voluntary  organization  that  works  to  create  open  and  Extensible  software 
interfaces  based  on  current  technologies  and  standards.  This  organization  is  responsible  for  the  GML 
Implementation  Specification. 
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Mapping  M-COP  Categories  to  JC3IEDM  (C2IEDM) 

The  C2IEDM  is  a  common  data  model  established  by  the  Multilateral 
Interoperability  Programme  (MIP)  for  interchange  of  operations  data 
across  multinational  command  and  control  systems  (MIP  2005b).  The 
DOD  has  a  number  of  initiatives  underway  to  employ  C2IEDM  for  data 
exchange  with  Coalition  forces  (DUSD  2004)  and  as  a  basis  for  data  inter¬ 
change  (Koontz  2005).  Additionally,  the  U.S.  Army  is  standardizing  on 
C2IEDM  for  data  exchange,  not  just  between  command  and  control  sys¬ 
tems,  but  also  between  M&S  systems  and  command  and  control  systems. 
The  C21EDM  has  been  endorsed  by  the  Army  DCS,  G-3/5/7,  the  Army 
CIO/G-6,  and  the  Commander,  Army  Combined  Arms  Center,  as  the  stan¬ 
dard  for  information  exchange  in  Battle  Command  systems.  C2IEDM  is  a 
principal  representation  for  the  emerging  C-BML  standard  coming  out  of 
the  SISO  (Galvin  et  al.  2005).  XML  Schema  definitions  for  both  physical 
and  logical  views  of  C2IEDM  have  been  registered  in  the  DOD  Metadata 
Registry  and  Clearinghouse  for  broad  use  across  the  warfighting  commu¬ 
nity  (DOD  2005).  As  a  common  interchange  format  that  will  play  an 
important  role  in  the  future  GIG,  it  is  important  to  consider  the  ability  to 
express  required  M-COP  information  in  C2IEDM.  If  gaps  exist,  in  terms  of 
M-COP  data  requirements  that  cannot  be  represented  in  C2IEDM,  then 
extensions  to  the  C2IEDM  can  be  recommended  for  possible  inclusion  in 
future  versions  of  the  model.  Short  of  international  acceptance  of  the 
extensions,  community  acceptance  and  employment  of  specific  extensions 
can  still  become  standard  practice  in  U.S.  command  and  control  and  M&S 
communities  to  achieve  M-COP  objectives  in  ground  movement  planning. 

At  the  time  of  the  writing  of  this  report,  the  MIP  has  specified  a  follow-on 
model  to  C2IEDM  called  the  Joint  C3  Information  Exchange  Data  Model 
(JC3IEDM)  (MIP  2005b).  As  this  appears  to  be  the  next  evolution  of  the 
data  model,  our  mapping  was  done  against  the  JC3IEDM  specification. 
Information  needed  for  the  M-COP  determined  to  be  missing  from  the 
JC3IEDM  can  be  recommended  to  the  community  as  extensions.  Simple 
extensions  are  considered  to  be  additional  values  to  existing  enumera¬ 
tions.  Straightforward  extensions  are  identification  of  additional  attributes 
to  an  existing  entity.  Structural  extensions  are  identification  of  additional 
entities  and  their  attributes  to  the  model,  likely  to  include  addition  of 
cross-reference  tables  relating  the  new  entities  to  others.  The  level  of  com¬ 
plexity  of  the  proposed  extensions  may  affect  acceptance  and  adoption, 
but  should  be  proffered  nonetheless  to  create  community  awareness  of  M- 
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COP  requirements  and  cause  appropriate  consideration  of  the  recom¬ 
mended  extensions. 

Relevant  JC3IEDM  Structure 

JC3IEDM  uses  the  name  OBJECT-TYPE  to  refer  to  class  objects  and 
OBJECT-ITEM  for  individually  identified  instances.  Implicit  in  the 
distinction  between  type  and  item  is  the  assumption  that  data  relating  to 
OBJECT-TYPEs  will  tend  to  be  relatively  static  or  persistent  (i.e.,  the  val¬ 
ues  of  the  attributes  are  not  likely  to  change  very  often  over  time),  whereas 
the  data  characteristics  related  to  OBJECT-ITEMs  are  likely  to  be  more 
dynamic. 

Item  and  type  objects  are  subdivided  into  extensive  hierarchies.  There  are 
five  categories  or  subtypes  to  encompass  any  object  within  the  scope  of  the 
model:  facility,  feature,  materiel,  organization,  and  person  (Table  12).  As 
may  be  expected,  the  two  sets  osf  definitions  are  similar.  The  item  and 
type  objects  have  attributes  and  specific  instances  or  enumerations. 


Table  12.  Definition  of  first-level  JC3IEDM  subtypings. 


Entity 

Entity  Definition 

FACILITY 

An  OBJECT-ITEM  that  is  built,  installed,  or  established  to  serve  some  particular  purpose 
and  is  identified  by  the  service  it  provides  rather  than  by  its  content. 

FACILITY-TYPE 

An  OBJECT-TYPE  that  is  intended  to  be  built,  installed,  or  established  to  serve  some 
particular  purpose  and  is  identified  by  the  service  it  is  intended  to  provide  rather  than 
by  its  content.  Examples  include  a  refueling  port,  a  field  hospital,  and  a  command  post. 

FEATURE 

An  OBJECT-ITEM  that  encompasses  meteorological,  geographic,  and  control  features  of 
military  significance. 

FEATURE-TYPE 

An  OBJECT-TYPE  that  encompasses  meteorological,  geographic,  and  control  features  of 
military  significance.  Examples  include  a  forest,  an  area  of  rain,  a  river,  an  area  of 
responsibility. 

MATERIEL 

An  OBJECT-ITEM  that  is  equipment,  apparatus,  or  supplies  without  distinction  as  to  its 
application  for  administrative  of  combat  purposes. 

MATERIEL-TYPE 

An  OBJECT-TYPE  that  represents  equipment,  apparatus  or  supplies  of  military  interest 
without  distinction  to  its  application  for  administrative  or  combat  purposes.  Examples 
include  ships,  tanks,  self-propelled  weapons,  aircraft,  etc.,  and  related  spares,  repair 
parts,  and  support  equipment,  but  excluding  real  property,  installations,  and  utilities. 

ORGANIZATION 

An  OBJECT-ITEM  that  is  an  administrative  or  functional  structure. 

ORGANIZATION-TYPE 

An  OBJECT-TYPE  that  represents  administrative  or  functional  structures. 

PERSON 

An  OBJECT-ITEM  that  is  a  human  being  to  whom  military  or  civilian  significance  is 
attached. 

PERSON-TYPE 

An  OBJECT-TYPE  that  represents  human  beings  about  whom  information  is  to  be  held. 
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M-COP  Terrain  Category  Relationships  to  the  JC3IEDM 

Table  13  shows  a  comparison  between  the  M-COP  Terrain  category  classes 
and  subclasses,  and  the  JC3IEDM  representations.  There  is  some  align¬ 
ment  in  regards  to  the  J3CIEDM  category  codes  for  FEATURE  and 
FACILITY,  and  their  attributes  provide  additional  information,  much  like 
other  data  models;  however,  there  are  only  a  few  JC3IEDM  entities  that 
have  more  than  basic  attribute  information,  and  they  do  not  contain  the 
information  required  for  the  M-COP. 


Table  13.  Association  of  M-COP  Terrain  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Terrain  Class  or  Subclass 

Corresponding  JC3IEDM  Entity  or  Attribute 

NATURAL_REGION 

OPEN_TRACT 

FACILITY 

SITE 

WATERBODY 

ROAD 

Terrain  can  be  represented  as  an  OBJECT-TYPE,  FEATURE-TYPE, 
GEOGRAPHIC-FEATURE-TYPE  with  an  attribute  of 
geographic-feature-type-category-code 

As  an  OBJECT-ITEM,  FEATURE,  GEOGRAPHIC-FEATURE  with  attributes  of 
geographic-feature-solid-surface-composition-code 
geographic-feature-surface-category-code 
geographic-feature-terrain-code 
geographic-feature-vegetation-code 

Facilities  can  be  represented  as  an  OBJECT-TYPE,  FACILITY-TYPE  which 
has  an  attribute  of 

facility-type-category-code 
and  as  an  OBJECT-ITEM,  FACILITY  with  attributes  of 
facility-category-code 

The  J3CIEDM  codes  align  with  some  of  the  M-COP  FEATURE-TYPE  are 
indicated  in  the  first  column  of  Tables  A1-A6. 

TRAFFICABILITY_SURFACE 

TRAFFICABILITY_VEGETATION 

TRAFFICABILITY_WETGAPS 

TRAFFICABILITY_DRYGAPS 

MANEUVERJJRBAN 

The  object-item-status-category-code,  GEOGRAPHIC-FEATURE-STATUS  is 
a  record  of  condition  of  a  specific  geographic  feature.  The  geographic- 
feature-surface-category-code  has  sub-attributes  related  to  liquid,  and 
solid  surfaces,  including  firmness  code  related  to  trafficability,  but  it  is 
not  sufficient  for  the  M-COP.  Additional  surface  status  information 
relates  to: 

solid-surface-status-code 

Cleared  Contaminated  Destroyed 

Heavily  damaged  Lightly  damaged  Moderately  damaged 

Obstructed  Not  known 

solid-surface-status-surface-condition-code 

Dust  Earth  Flood  Ice  Sand 

Snow  Not  known  Not  otherwise  specified 

Additionally,  facilities  also  have  a  FACILITY-STATUS,  which  adds  a  little 
more  of  the  required  attribution,  it  is  not  sufficient  for  the  M-COP. 
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Table  13  (cont.).  Association  of  M-COP  Terrain  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Terrain  Class  or  Subclass 

Corresponding  JC3IEDM  Entity  or  Attribute 

TRAFFICABILITY_ROADS 

The  FACILITY  entity  ROAD  has  the  following  attributes: 
road-id 

road-category-code 

road-shoulder-width-code 

road-traffic-density-count 

road-weather-condition-category-code 

road-quality-code 

These  attributes  only  partially  meet  the  needs  of  the  M-COP. 

TRAFFICABILITY_BRIDGES_TUNNEL 

The  FACILITY  entity  BRIDGE  has  the  following  attributes: 
bridge-id 

bridge-longest-span-length-dimension 

bridge-span-count 

bridge-usage-code 

bridge-type-id 

bridge-type-design-type-code 

These  attributes  only  partially  meet  the  needs  of  the  M-COP,  and  there 
are  no  attributes  for  tunnels. 

TRAFFICABI  LITY_RAI  LROAD 

The  FACILITY  entity  RAILWAY  has  the  following  attributes: 
railway-id 

railway-track-gauge-code 

railway-track-count 

railway-train-density-count 

railway-block-distance-dimension 

railway-sleeper-density-dimension 

ra  i  1  way-gross-tra  i  1  i  ng-l  oad-q  ua  ntity 

railway-maximum-speed-rate 

railway-traction-system-code 

railway-signal-system-code 

railway-signal-system-efficiency-code 

These  attributes  only  partially  meet  the  needs  of  the  M-COP. 

Comparing  the  GEOGRAPHIC-FEATURE-STATUS  to  the  M-COP  sub¬ 
classes,  we  see  that  the  M-COP  subclasses  can  be  represented  in  the 
JC3IEDM  respectively: 

•  GEOGRAPHIC-FEATURE -TRAFFICABLITIY-SURF ACE-STATUS 

•  GEOGRAPHIC-FEATURE -TRAFFICABLITIY-VEGETATION-STATUS 

•  GEOGRAPHIC-FEATURE -TRAFFICABLITIY-GAP-STATUS 

with  the  corresponding  attributes  as  specified  in  Tables  A7-A10.  The  traf- 
ficability  attributes  associated  with  roads,  railroads,  bridges,  and  tunnels 
will  need  to  be  split  up  among  the  JC3IEDM  FACILITY-TYPE,  FACILITY, 
and  FACILITY-STATUS.  With  these  extensions,  the  M-COP  Terrain  cate- 
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gory  can  be  represented  within  the  JC3IEDM,  although  some  further  for¬ 
malization  and  analysis  remains  to  be  done. 

M-COP  Obstacle  Category  Relationships  to  the  JC3IEDM 

Several  classes  (entities)  of  obstacles  are  identified  in  JC3IEDM;  trenches, 
wire,  and  berms  are  described  through  use  of  the  military-obstacle-type- 
category-code,  but  provide  only  the  type,  with  no  additional  attributes 
(such  as  depth  or  height)  required  for  the  M-COP.  The  JC3IEDM 
entity/ attributes  that  seem  to  align  with  the  M-COP  obstacles  are  indi¬ 
cated  in  Table  Bi.  Minefields  are  very  well  described,  but  they  lack 
information  on  trafficability  over  the  terrain  and  complete  alignment  with 
allowable  attribute  values,  as  shown  in  Table  14.  The  JC3IEDM  allows 
instances  of  OBJECT-ITEMs  to  have  a  relationship  or  association  to  other 
instances  of  an  OBJECT-ITEM.  This  association  allows  a  FACILITY,  such 
as  a  Military-Obstacle,  to  be  associated  to  Feature  as  in,  for  example,  “Is 
situated  in.”  Thus,  the  underlying  terrain  attributes  required  for 
trafficability  can  be  “connected”  with  the  JC3IEDM  obstacles.  However, 
further  attribution  is  still  needed  for  the  non-minefield  type  obstacles,  and 
these  specific  attributions  will  need  to  be  individually  formalized,  based  on 
the  type  of  obstacle. 


Table  14.  Association  of  M-COP  MINEFIELD  class  and  the  JC3IEDM. 


M-COP  MINEFIELD  Class  Attributes 

Corresponding  J3CIEDM  Entity  and  Attribute  Names 

TRAFFICABILITY_SURFACE 

See  Terrain  discussion  above  and  Table  15. 

MINEFIELD-LAND 

minefield-land-depth-placement-code 

Case_Burial_Fraction 

Comment:  there  is  not  a  direct  and  complete  mapping  between  the 
allowable  values. 

OBJECT-ITEM,  FACILITY-STATUS 

operational-status-qualifier-code 

Completion_Precentage 

Comment:  there  is  not  a  direct  and  complete  mapping  between  the 
allowable  values. 

Prepared_Explosive_ 

Destruction_Completion_Fraction 

OBJECT-ITEM,  FACILITY-STATUS 

facility-status-demolition-status-code 

General_Damage_Fraction 

Comment:  there  is  not  a  direct  and  complete  mapping  between  the 
allowable  values. 
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Table  14  (cont.).  Association  of  M-COP  MINEFIELD  class  and  the  JC3IEDM. 


M-COP  MINEFIELD  Class  Attributes 

Corresponding  J3CIEDM  Entity  and  Attribute  Names 

Explosive_Mine_Type 

OBJECT-TYPE,  MILITARY-OBSTACLE-TYPE 
military-obstacle-type-category-code 

OBJECT-ITEM,  MINEFIELD 
minefield-category-code 

OBJECT-ITEM,  MINEFIELD-LAND 

minefield-land-function-code 

OBJECT-ITEM,  MINEFIELD-MARITIME 

minefield-maritime-depth-placement-code 

Comment:  Requires  several  different  J3IEDM  attributes  to  map  to  the 
M-COP  attribute  values 

Duration_Overview 

OBJECT-ITEM,  MINEFIELD-LAND 

Minefield-land-persistence-code 

Minefield_Marking_Type 

Not  found 

Numeric_Object_ldentifier 

OBJECT-ITEM,  MILITARY-OBSTACLE-TYPE 
military-obstacle-type-id 

Forcejdentifier 

Mine_Allegiance 

An  OBJECT-ITEM,  ORGANISATION  can  be  associated  with  the  FACILITY- 
MINEFIELD,  and  the  object-item-status-hostility-code  contains  the 
Mine_Allegiance  information. 

M-COP  Weather  Category  Relationships  to  the  JC3IEDM 

Table  15  shows  a  comparison  between  the  M-COP  Weather  category 
classes  and  the  JC3IEDM  representations.  The  JC3IEDM  entity 
METEOROLOGIC-FEATURE  has  seven  classes:  ATMOSPHERE,  CLOUD- 
COVER,  ICING,  LIGHT,  PRECIPITATION,  VISIBILITY,  and  WIND.  Each 
instance  of  METEOROLOGIC-FEATURE  describes  a  single  meteorological 
condition  at  a  specific  location  and  time,  and  each  condition  is  either 
observed  or  forecasted. 

There  is  good  alignment  between  the  M-COP  classes  and  the  JC3IEDM 
entity  METEOROLOGIC-FEATURE.  In  the  case  of  the  M-COP  Weather 
classes  ATMOSPHERE,  PRECIPITATION,  CLOUD_COVER,  ICING, 
LIGHTING_AND_VISIBILITY,  and  WIND,  not  all  of  the  M-COP  attrib¬ 
utes  map  to  JC3IEDM. 
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Table  15.  Association  of  M-COP  Weather  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Weather  Class 

Corresponding  JC3IEDM  Entity  or  Attribute 

PRECIPITATION 

An  entity  of  METEOROLOGIC-FEATURE  meteorologic-feature- 
category-code.  The  attributes  for  PRECIPITATION  are: 
precipitation-category-code 
precipitation-rate 

These  attributes  only  partially  meet  the  needs  of  the  M-COP.  There 
are  no  attributes  for  precipitation  accumulation,  precipitation 
intensity,  snow  depth,  precipitation  or  thunderstorm  probability. 

ATMOSPHERE 

ATMOSPHERE  is  an  entity  of  METEOROLOGIC-FEATURE 
meteorologic-feature-category-code.  The  attributes  for  ATMOSPHERE 
are: 

atmosphere-humidity-ratio 

atmosphere-inversion-layer-code 

atmosphere-pressure-rate 

atmosphere-pressure-system-category-code 

atmosphere-temperature 

atmosphere-temperature-gradient-code 

These  attributes  only  partially  meet  the  needs  of  the  M-COP.  There 
are  no  attributes  for  dew  point,  lightning,  or  climatology. 

WIND 

An  entity  of  METEOROLOGIC-FEATURE  meteorologic-feature- 
category-code.  The  attributes  for  WIND  are: 
wind-category-code 
wi  n  d-a  i  r-sta  bi  1  ity-category-code 
wind-altitude-layer-code 
wind-direction-angle 
wind-effective-downwind-direction-angle 
wind-speed-rate 

wind-nuclear-yield-qualifier-code 

These  attributes  only  partially  meet  the  needs  of  the  M-COP.  There 
are  no  attributes  for  wind  speed  u,  v  components  or  climatology. 

CLOUD_COVER 

CLOUD-COVER  is  an  entity  of  METEOROLOGIC-FEATURE 
meteorologic-feature-category-code.  The  attributes  for  CLOUD- 
COVER  are: 

cloud-cover-category-code 

cloud-cover-base-dimension 

cloud-cover-top-dimension 

cloud-cover-average-coverage-code 

cloud-cover-light-refraction-ratio 

These  attributes  only  partially  meet  the  needs  of  the  M-COP.  There 
are  no  attributes  for  cloud  type,  high,  medium,  or  low  clouds. 
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Table  15  (cont.).  Association  of  M-COP  Weather  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Weather  Class 

Corresponding  JC3IEDM  Entity  or  Attribute 

LIGHTING_AND_VISIBILITY 

VISIBILITY  is  an  entity  of  METEOROLOGIC-FEATURE  meteorologic- 
featu re-category-code.  The  attributes  for  VISIBILITY  are: 
visibility-category-code 
visibility-direction-code 
visibility-range-dimension 

LIGHT  is  an  entity  of  METEOROLOGIC-FEATURE  meteorologic-feature- 
category-code.  The  attributes  for  LIGHT  are: 
light-category-code 
light-up-datetime 

1  ight-d  own-dateti  me 
light-moon-phase-code 

ICING 

An  entity  of  METEOROLOGIC-FEATURE  meteorologic-feature- 
category-code.  The  attributes  for  ICING  are: 
icing-category-code 
i  ci  n  g-seve  r  ity-q  u  a  1  if  i  e  r-cod  e 

These  attributes  only  partially  meet  the  needs  of  the  M-COP.  There 
are  no  attributes  for  probability  of  icing. 

M-COP  Maneuver  Analysis  Category  Relationships  to  the  JC3IEDM 

Only  a  few  classes  (entities)  from  the  Maneuver  Analysis  category  are 
represented  directly  in  JC3IEDM;  additionally,  there  are  other  categories 
that  are  not  found  explicitly  but  can  be  constructed  through  relationships 
and  associations.  Also,  there  are  a  few  items  that  would  likely  need  to  be 
added.  Table  16  contains  a  summary  of  the  M-COP  Maneuver  Analysis 
classes  and  attributes,  along  with  corresponding  JC3IEDM  representa¬ 
tions  and  notes. 

Areas  of  operations,  key  terrain,  and  engagement  areas  seem  to  be  suffi¬ 
ciently  described.  On  the  other  hand,  trafficability  segments,  avenue  of 
approach  segments,  and  time  phase  lines  can  be  derived  by  relationships 
and  associations.  Further  attribution  is  needed  in  most  cases  for  all 
classes.  Classes  for  trafficability  sector,  mobility  corridor,  and  avenue  of 
approach  channelizer  were  not  found  and  would  need  to  be  developed, 
along  with  their  attributes,  as  extensions  to  the  JC3IEDM. 


66 


ERDC  TR-07-4 


Table  16.  Association  of  M-COP  Maneuver  Analysis  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Maneuver  Analysis  Classes  and  Attributes 

Corresponding  JC3IEDM  Entity  or  Attribute 

AREA_OF_OPERATIONS  (AO) 

Is  a  control-feature-type-category-code  (attribute  of  an 
OBJECT-ITEM) 

Name 

OBJECT-ITEM  name 

Commander 

An  ORGANIZATION  can  have  an  association  (Is  under 
command  of)  with  a  PERSON 

Unit 

OBJECT-ITEMs  can  have  an  associated  UNIT,  alternatively 
an  ORGANIZATION  can  have  an  association  (Controls, 
bounded  by,  etc)  with  a  control  measure 

GEOMETRY* 

OBJECT-ITEMs  have  a  LOCATION  which  can  be  a  POLYGON 
AREA 

TRAFFICABILITY_SECTOR  (TS) 

Not  found,  although  control  feature  category  codes:  no-go 
area  and  slow-go  area  can  be  identified,  they  are  not 
sufficient  to  meet  the  needs  of  this  M-COP  class 

Name 

OBJECT-ITEM  name 

AO_Name 

OBJECT-ITEM  name 

Unit 

As  above 

Trafficability_Estimate 

Not  found 

Speed 

Not  found 

FORCE_DISPOSITION 

Affliation 

An  ORGANIZATION  can  be  associated  with  a  CONTROL 
FEATURE 

GROUND_AVENUE_OF_APPROACH  (AA) 

Is  similar  to  Axis  of  Advance, t  a  control-feature-type- 
category-code  (which  is  an  OBJECT-ITEM) 

Name 

OBJECT-ITEM  name 

AO_Name 

OBJECT-ITEMs  can  be  related  to  each  other  using  the 
JC3IEDM  business  rules,  in  this  case  the  OBJECT-ITEM 
CONTROL  FEATURE  Area  of  Operations  “Encloses”  the  Axis 
of  Advance,  where  “Encloses”  is  the  object-item 
association-category-code 

Number  _Of_AA_Segments 

Not  found 

Number_Of_Mobility_Corridors 

Not  found 

*  All  of  the  classes  in  this  table  require  a  geometry,  this  class  is  not  repeated  in  this  table. 

t  While  the  U.S.  Army  differentiates  between  an  Avenue  of  Approach  and  Axis  of  Advance,  the  J3CIEDM 
definition  for  Axis  of  Advance  “A  general  route  of  advance,  assigned  for  control,  which  extends  towards 
the  enemy.  An  axis  of  advance  symbol  graphically  portrays  a  commander's  intention,  such  as 
avoidance  of  built-up  areas  or  envelopment  of  an  enemy  force.  It  follows  terrain  suitable  for  the  size  of 
the  force  to  which  the  axis  was  assigned,  and  is  often  a  road,  a  group  of  roads,  or  a  designated  series 
of  locations.  An  axis  of  advance  is  not  used  to  direct  the  control  of  terrain  or  the  clearance  of  enemy 
forces  from  specific  locations.  Intermediate  objectives  are  normally  assigned  for  these  purposes.”  This 
definition  seems  to  describe  the  U.S.  usage  of  the  term  Avenue  of  Approach. 
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Table  16  (cont.).  Association  of  M-COP  Maneuver  Analysis  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Maneuver  Analysis  Classes  and  Attributes 

Corresponding  JC3IEDM  Entity  or  Attribute 

Force_Size 

An  ORGANIZATION  can  be  associated  with  a  CONTROL 
FEATURE 

FORCE_DISPOSITION 

Affliation 

As  above 

General_Direction 

Not  found 

MOBILITY_CORRIDOR  (MC) 

Not  found 

Name 

OBJECT-ITEM  name 

AA_Name 

OBJECT-ITEM  name,  can  be  associated 

Force_Size 

An  ORGANIZATION  can  be  associated  with  a  CONTROL 
FEATURE 

Restriction 

Not  found 

Characteristic_Width 

Not  found 

Trafficability_Estimate 

Not  found 

Reason 

Not  found 

AVENUE_OF_APPROACH_CHANNELIZER 

Not  found 

Name 

OBJECT-ITEM  name 

AA_Name 

OBJECT-ITEM  name,  can  be  associated 

AA_Segment_Mobility_Corridor_l 

Not  found 

AA_Segment_Mobility_Corridor_2 

Not  found 

AVENUE_OF_APPROACH_SEGMENT 

CONTROL  FEATURES  can  be  linked  together  using  the 
object-item-association-category-code  (is  part  of); 
alternatively,  if  the  attributes  are  all  the  same  the 

POLYGON  AREA  can  represent  the  segmented  of  the  AA 

AA_Name 

OBJECT-ITEM  name 

Segment_Number 

Not  found 

Segment_Width 

Not  found 

Segment_Visual_Obstructions 

Not  found 

Segment_Concealment 

Not  found 

Segment_Cover 

Not  found 

KEY_TERRAIN 

Is  a  control-feature-type-category-code  (which  is  an 
OBJECT-ITEM) 

Name 

OBJECT-ITEM  name 

AO_Name 

OBJECT-ITEM  name,  can  be  associated 

Key_Terrain_Type 

This  OBJECT-ITEM  can  be  associated  with  a  specific 
Geographic-Feature  Object-item 
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Table  16  (cont.).  Association  of  M-COP  Maneuver  Analysis  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Maneuver  Analysis  Classes  and  Attributes 

Corresponding  JC3IEDM  Entity  or  Attribute 

Reason 

Not  found,  however  by  association  with  an  organization  the 
reason  may  be  apparent 

FORCE_DISPOSITION 

Affliation 

As  above 

ENGAGEMENT_AREA  (EA) 

Is  a  control-feature-type-category-code  (which  is  an 
OBJECT-ITEM) 

Name 

OBJECT-ITEM  name 

AO_Name 

OBJECT-ITEM  name,  can  be  associated 

AA_Name 

OBJECT-ITEM  name,  can  be  associated 

Unit 

Can  be  associated  (as  above  in  this  table) 

Fire_Type 

Can  be  associated  through  use  of  a  JC3IEDM  ACTION 

EnemyJJnit 

Associated  as  above  (in  this  table)  along  with  specifying 
the  unit  is  hostile  (see  Threat  Analysis  below) 

Enemy_Fire_Type 

Associated  as  in  THREAT_COURSE_OF_ACTION  below 

Initiator 

Specified  by  associating  an  ACTION 

TIME_PHASE_LINE_H  (TPL) 

Phase  Line  is  a  control-feature-type-category-code  (which  is 
an  OBJECT-ITEM)  to  associate  it  with  a  time  requires 
association  with  an  ORGANIZATION  with  an  ACTION 

Name 

OBJECT-ITEM  name 

AO_Name 

OBJECT-ITEM  name,  can  be  associated 

Timejncrements 

See  Phase  Line  above  in  this  table 

TPL_PT_1 

See  Phase  Line  above  in  this  table 

TPL_PT_2 

See  Phase  Line  above  in  this  table 

FORCE_DISPOSITION 

Identity 

Affliation 

Organization  can  be  associated 

M-COP  Route  Finding  Category  Relationships  to  the  JC3IEDM 

Table  17  contains  a  summary  of  the  M-COP  Route  Finding  classes  and 
attributes,  along  with  corresponding  JC3IEDM  representations  and  notes. 
There  are  three  changes  to  JC3IEDM  that  would  go  far  in  accommodating 
information  from  the  Route  Finding  category.  One  is  the  generalization  of 
the  JC3IEDM  NETWORK  entity.  As  specified,  a  NETWORK  entity  repre¬ 
sents  an  electronic  communications  network  FACILITY.  If  the  NETWORK 
entity  were  generalized  to  be  a  graph  construct,  a  maneuver  network  graph 
could  be  represented  as  well  as  other  types  of  graphs— including  electron- 
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ics  communication  networks.  Other  potential  networks  include  main 
supply  ROUTES  and  alternate  supply  ROUTES,  AIR-ROUTE-SEGMENT 
networks,  or  a  network  showing  intersections  between  CONTROL- 
FEATUREs.  Additionally,  the  notion  of  a  “general-vehicle-type,”  would, 
like  the  existing  unit-type-general-mobility-code,  allow  characterization  of 
trafficability  without  specific  vehicle-types.  Lastly,  addition  of  a  construct 
to  allow  the  expression  of  the  M-COP  class  CONSTRAINTS  for  Route  Find¬ 
ing  would  enhance  JC3IEDM  as  a  model  for  accommodating  route 
requests.  Considerations  for  routing  are  legion,  and  the  need  for  routing  as 
a  GIG  service  is  obvious.  However,  the  current  JC3IEDM  is  missing  this 
important  aspect  of  joint  operations  information.  Other  comparisons  to 
JC3IEDM  are  made  in  Table  17. 


Table  17.  Association  of  M-COP  Route  Finding  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Route  Finding  Classes  and  Attributes 

Corresponding  JC3IEDM  Entity  or  Attribute 

ROUTE 

ROUTE 

Route_Purpose 

Not  found 

Route_Classifi  cation 

Not  found 

Start_Point 

POINT 

Stop_Point 

POINT 

Edge_List 

Not  found 

ROUTE_REQUEST 

REQUEST 

Start_Point 

POINT 

Stop_Point 

POINT 

Way_Point 

POINT 

Datetime 

Not  found 

Constraint_List 

Not  found 

Constraint_Weight_List 

Not  found 

CONSTRAINT 

Not  found 

Force 

Not  found 

Constraint_Type 

Not  found 

Control_Measure 

CONTROL_FEATURE 

Geometry 

LOCATION  -  can  be  a  POLYGON  AREA,  LINE,  or  POINT 

Feature 

FEATURE 

Feature_Type 

FEATURE_TYPE 

Obstacle 

OBSTACLE 

Obstacle_Type 

OBSTACLE_TYPE 
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Table  17  (cont.).  Association  of  M-COP  Route  Finding  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Route  Finding  Classes  and  Attributes 

Corresponding  JC3IEDM  Entity  or  Attribute 

MANEUVER_NETWORK_GRAPH 

Not  found 

Edge_List 

Not  found 

Node_List 

Not  found 

Maneuver_Network_Type 

Not  found 

Network_Junction 

Not  found 

EDGE 

Not  found 

NodeA 

Not  found 

NodeB 

Not  found 

Feature 

FEATURE 

Width 

Not  found 

Off_Road_Shortest 

MOBILITY-CAPABILITY 

On_Road_Shortest 

MOBILITY-CAPABILITY 

Military_Load_Classifi  cation 

MOBILITY-CAPABILITY 

General_Vehicle_Speed 

MOBILITY-CAPABILITY 

General_Vehicle_Type_Time 

MOBILITY-CAPABILITY 

General_Vehicle_Type_Off_Road_Fastest 

MOBILITY-CAPABILITY 

General_Vehicle_Type_On_Road_Fastest 

MOBILITY-CAPABILITY 

Concealment 

Not  found 

Radius_of_Curvature 

Not  found 

NODE 

Not  found 

Geometry 

POINT 

Edge 

Not  found 

FORCE 

MILITARY-ORGANISATION-TYPE 

Width 

unit-type-size-code 

Formation_Type 

TASK-FORMATION-TYPE 

Vehicle_Type 

VEHICLE-TYPE 

General_Vehicle_Type 

VEHICLE-TYPE 

M-COP  Threat  Analysis  Category  Relationships  to  the  JC3IEDM 

Recall  that  many  of  the  classes  associated  with  the  Threat  Analysis  cate¬ 
gory  are  subsumed  in  the  Maneuver  Analysis  category.  The  reader  can 
refer  to  that  section  for  maneuver  analysis  classes  and  concepts  associated 
with  analyzing  the  maneuver  potential  of  the  threat.  The  two  classes  and 
associated  attributes  identified  to  meet  the  needs  of  the  M-COP  in  regards 
to  Threat  Analysis  are  summarized  in  Table  18.  The  table  also  contains  the 
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corresponding  JC3IEDM  entities  or  further  notes.  For  this  category,  there 
is  good  correlation  between  M-COP  categories  and  JC3IEDM  representa¬ 
tions. 


Table  18.  Association  of  M-COP  Threat  Analysis  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Threat  Analysis  Classes  and  Attributes  (indented) 

Corresponding  JC3IEDM  Entities  and  Attributes 

THREAT_COURSE_OF_ACTION 

THREAT_COURSE_OF_ACTION  can  be  represented 
by  specifying  an  ACTION  and  CONTEXT  with  a  value 
of  “prediction”  for  a  hostile  unit 

Course_Of_Action_Name 

ACTION  has  a  name 

Threat_Unit_Name 

A  unit  name  with  an  object-item-status-hostility- 
code  of  hostile 

Threat_Unit_Objective_Location 

OBJECT-ITEM  CONTROL-FEATURE  type-objective 
area,  associated  with  the  threat  unit 

Threat_Unit_What 

Specified  with  ACTION-EFFECT 

Threat_Unit_When 

Specified  with  ACTION-TEMPORAL-ASSOCIATION 

Th  reat_U  n  it_Wh  ere 

Specified  with  LOCATION 

SITUATION_TEMPLATE 

A  template  per  se  does  not  appear  to  exist; 
however,  objects  and  relationships  are  available  to 
create  one 

Unit_Type 

See  Forces  below 

Unit_Name 

See  Forces  below 

Unit_Locations 

See  Forces  below 

Time_Phase_Line_H 

Phase  lines  exist  as  a  control-feature-type-category- 
code 

High_Value_Target_X_Location 

Represented  within  the  context  of  CANDIDATE- 
TARGET-LIST 

Each  OBJECT-ITEM  within  the  J3CIEDM  can  have  an  object-item-status- 
hostility-code,  which  provides  a  value  that  specifies  its  perceived  level  of 
threat;  the  allowable  values  are: 

•  Assumed  friend  An  OBJECT-ITEM  that  is  assumed  to  be  a  friend 

because  of  its  characteristics,  behavior  or  origin. 

•  Assumed  hostile  An  indication  that  the  OBJECT-ITEM  in  question 

is  likely  to  belong  to  enemy  forces. 

•  Assumed  involved  An  indication  that  the  OBJECT-ITEM  in  question 

is  likely  to  belong  to  involved  forces  different  from 
own,  allied  and  enemy  forces. 
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Assumed  neutral 

An  indication  that  the  OBJECT-ITEM  in  question 
is  likely  to  belong  to  neither  own,  allied,  enemy,  or 
otherwise  involved  forces. 

Faker 

An  OBJECT-ITEM  that  is  a  friendly  aircraft 
simulating  a  hostile  aircraft  in  an  air  defense 
exercise. 

Friend 

An  OBJECT-ITEM  that  belongs  to  a  declared 
friendly  nation. 

Hostile 

An  OBJECT-ITEM  that  is  positively  identified  as 
enemy. 

Involved 

An  indication  that  the  OBJECT-ITEM  in  question 
belongs  to  involved  forces  different  from  own, 
allied  and  enemy  forces. 

Joker 

An  OBJECT-ITEM  that  is  acting  as  a  suspect  track 
for  exercise  purposes  only. 

Neutral 

An  OBJECT-ITEM  whose  characteristics, 
behavior,  origin,  or  nationality  indicate  that  it  is 
neither  supporting  friendly  nor  opposing  forces. 

Pending 

An  OBJECT-ITEM  for  which  identification  is  to  be 
determined. 

Suspect 

An  OBJECT-ITEM  that  is  potentially  hostile 
because  of  its  characteristics,  behavior  or  origin. 

Unknown 

An  OBJECT-ITEM  for  which  hostility  status 
information  is  not  available. 

M-COP  Forces  Category  Relationships  to  the  JC3IEDM 

Earlier  in  this  report  (Table  9),  the  data  elements  identified  for  the  Forces 
category  of  the  M-COP  data  model  were  mapped  to  elements  of  the  MSDL. 
The  developers  of  MSDL  have  been  keenly  aware  of  the  history  and 
application  of  C2IEDM  (and  the  new  JC3IEDM)  for  data  interchange 
across  BC  and  M&S  systems,  and  have  incorporated  a  small  set  of  C2IEDM 
enumerations  into  the  current  MSDL  schema  (specifically,  enumerations 
for  ActivityType).  Given  the  widespread  and  growing  international  adop¬ 
tion  of  C2IEDM  and  the  upcoming  JC3IEDM,  ongoing  standardization 
work  in  SISO  on  MSDL  and  the  related  C-BML  is  certain  to  create  more 
complete  linkages  with  JC3IEDM  data  and  data  structures. 

Information  identified  in  Table  9  describing  FORCE_DISPOSITION  is 
largely  available  in  JC3IEDM  in  the  OBJECT-ITEM  data  structure,  with 
related  LOCATION  information  that  will  describe  the  physical  geometry  of 
the  force  on  the  battlespace.  Specific  classes  of  vehicles  are  identified  in 
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the  OBJECT-TYPE  /  MATERIEL-TYPE  /  EQUIPMENT-TYPE  / 

VEHICLE -TYPE  hierarchy  (similar  hierarchy  under  OBJECT-ITEM  for 
individual  vehicles),  but  VEHICLE  characteristics  at  the  class  level  only 
include  a  type  identifier  and  vehicle  type  category  code,  with  additional 
features  regarding  physical  dimensions  and  logistical  information  about 
the  vehicle  inherited  from  the  higher  levels  of  the  data  structure.  Addi¬ 
tional  details  about  vehicle  characteristics  that  are  provided  in  NRMM  and 
the  STNDMob  API  need  to  be  added  as  an  extension  to  JC3IEDM. 

Planned  missions  of  a  force  are  described  under  the  ACTION  hierarchy, 
where  an  ACTION  is  defined  in  the  JC3IEDM  specification  as  “an  activity, 
or  the  occurrence  of  an  activity,  that  may  utilize  resources  and  may  be 
focused  against  an  objective.”  The  data  model  provides  a  rich  set  of  tempo¬ 
ral  descriptors  allowing  planned  actions  to  be  placed  in  temporal  relation 
to  each  other,  so  that  actions  can  be  specified  to  occur  some  time  before  or 
some  time  after  some  other  action,  among  other  options. 

Table  9  provided  an  association  of  the  data  identified  for  the  M-COP 
Forces  category  with  information  in  the  MSDL.  Similarly,  Table  19  pro¬ 
vides  a  mapping  of  the  Forces  data  requirements  with  JC3IEDM  entities 
and  attributes,  either  existing  or  as  potential  extensions  to  the  JC3IEDM. 
The  effort  here  does  not  intend  to  provide  precise  mapping  of  JC3IEDM  to 
the  Forces  concepts,  but  to  provide  a  summary  of  the  potential  for 
representation  of  the  M-COP  Forces  category  with  JC3IEDM  data 
structures. 


Table  19.  Association  of  M-COP  Forces  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Forces  Classes  and 
Attributes 

Corresponding  JC3IEDM  Entities  and  Attributes 

FORCE_DISPOSITION* 

Static  characteristic  data  at  an  organizational  level  is  found  in  OBJECT- 
TYPE  with  object-type-category-code  of  ORGANISATION-TYPE.  This  is 
further  partitioned  by  organization-type-category-code  to  CIVILIAN-POST- 
TYPE,  GOVERNMENT-ORGANISATION-TYPE,  GROUP-ORGANISATION-TYPE, 
PRIVATE-SECTOR-ORGANISATION-TYPE.  GOVERNMENT-ORGANISATION- 
TYPE  is  further  refined  by  MILITARY-ORGANISATION-TYPE,  with  military- 
organisation-type-category-code  of  UNIT-TYPE,  EXECUTIVE-MILITARY- 
ORGANISATION-TYPE,  MILITARY-POST-TYPE,  and  TASK-FORMATION-TYPE. 
Specific  organizations  (instances)  of  these  OBJECT-TYPEs  are  described  in 
a  parallel  structure  in  OBJECT-ITEM,  with  the  association  of  OBJECT-ITEM 
and  OBJECT-TYPE  provided  in  the  OBJECT-ITEM-TYPE  relation. 

*  As  in  Table  9,  dashes  and  indentation  in  Table  19  indicate  the  hierarchical  structure  of  the  data. 
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Table  19  (cont.).  Association  of  M-COP  Forces  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Forces  Classes  and 
Attributes 

Corresponding  JC3IEDM  Entities  and  Attributes 

-Identity 

OBJECT-ITEM/object-item-id  and  object-item-name-text.  Also,  OBJECT- 
ITEM/object-item-category-code=ORGANISATION/organization-category- 
code=UNIT/unit-id,  unit-formal-abbreviated-name-text,  and  unit- 
identification-text.  Similarly,  for  organization-category-code=CONVOY, 
identity  is  give  by  attribute  convoy-id.  In  addition  to  organizations,  OBJECT- 
ITEMs  for  individual  persons  and  equipment  (vehicles)  can  be  specified  in 
JC3IEDM. 

-Location 

Provided  by  LOCATION  and  associated  with  an  OBJECT-ITEM  through  the 
OBJECT-ITEM-LOCATION  relation.  The  location-category-code  attribute  of 
LOCATION  provides  description  as  GEOMETRIC-VOLUME,  POINT,  LINE,  or 
SURFACE,  allowing  extensive  variety  of  descriptions  of  the  geometry  of  the 
OBJECT-ITEM  in  the  further  subtypes  of  these  selections. 

-Formation 

Formation  is  the  geometric  arrangement  of  materiel  or,  in  the  aggregate, 
several  forces  on  the  battlefield.  Common  ground  combat  formations 
include  line,  vee,  wedge,  echelon  left  and  echelon  right.  JC3IEDM  uses  the 
term  “formation”  differently,  where  TASK-FORMATION-TYPE  is  defined  as 
“A  MILITARY-ORGANISATION-TYPE  that  is  constituted  on  a  temporary  or 
semi-permanent  basis  for  the  purpose  of  carrying  out  a  specific  operation, 
mission  or  task.”  The  desired  description  of  “formation”  for  ground 
maneuver  can  be  described  in  JC3IEDM  using  LOCATION,  OBJECT-ITEM- 
LOCATION,  and  OBJECT-REFERENCE  (special  case  of  RELATIVE- 
COORDINATE-SYSTEM)  to  create  a  relative  geometry  for  the  arrangement 
of  OBJECT-ITEMs  on  the  battlefield.  Some  enumeration  of  formations  (line, 
wedge,  etc.)  needs  to  be  added  to  JC3IEDM. 

-Formation  spacing 

As  above,  defined  by  the  relative  geometry  of  OBJECT-ITEMs  using 
LOCATION,  OBJECT-ITEM-LOCATION,  and  OBJECT-REFERENCE. 

-Orientation 

Attribute  object-item-location-bearing-angle  of  an  OBJECT-ITEM-LOCATION. 

-Size 

Attribute  unit-type-size-code  represents  the  relative  size  of  the  unit  (e.g., 
Battalion;  Brigade;  Company,  Platoon,  Squad,  Section,  Team). 

-Center  of  gravity 

Not  currently  specified  as  such,  but  can  be  expressed  through  the 

LOCATION  and  OBJECT-ITEM-LOCATION  structures. 

-Fields  of  fire 

In  LOCATION/location-category-code=SURFACE-AREA,  fields  of  fire  can  be 
represented  as  one  or  more  FAN-AREAs. 

-Plan 

Set  of  ACTION-TASKs. 

-Purpose 

ACTION/ACTION-EFFECT;  also  can  be  recorded  in  narrative  form  in 
attribute  action-task-detailed-text  of  ACTION-TASK. 

-Activity 

Attribute  action-task-activity-code  of  ACTION/ACTION-TASK  (e.g.,  Block, 
Breach,  Capture,  Constitute  a  flank  guard,  Cross,  Defend,  Delay,  Evacuate, 
Guard,  Intercept,  Interdict,  Jam,  Move,  Occupy,  Plan,  Reconnaissance, 
Redeploy,  Reinforce,  Reorganise,  Repair,  Resupply,  Screen,  Secure,  Set 
up,  Suppress,  Withdraw). 

-Task 

ACTION-TASK  structure. 

-Movement 

A  Movement  operation  is  a  specific  selection  from  the  action-task-activity- 
code  of  ACTION-TASK,  as  described  above.  UNIT-TYPE  as  a  subtype  of 
MILITARY-ORGANISATION-TYPE  has  a  unit-type-general-mobility-code  that 
represents  the  general  mobility  of  a  unit,  seen  as  a  whole.  Example  values 
are  Air,  fixed  wing;  Amphibious;  Land,  tracked. 
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Table  19  (cont.).  Association  of  M-COP  Forces  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Forces  Classes  and 
Attributes 

Corresponding  JC3IEDM  Entities  and  Attributes 

--Direction 

Attribute  object-item-location-bearing-angle  of  an  OBJECT-ITEM-LOCATION 

-Speed 

Attribute  object-item-location-speed-rate  of  an  OBJECT-ITEM-LOCATION 

-Movement  Plans 

See  above,  described  as  one  of  the  activity  types  that  can  be  specified  in 
a  Plan.  Also,  ROUTE  and  ROUTE-SEGMENT  are  subtypes  of  CONTROL- 
FEATURE  and  have  attributes  for  route-mobility-code  and  route-segment- 
mobility-code,  respectively,  to  indicate  the  suitability  of  a  particular 
ROUTE-SEGMENT  for  movement  (Foot,  Tracked,  Wheeled,  all  road; 

Wheeled,  general;  Wheeled  and  tracked;  Not  known). 

-Affiliation 

AFFILIATION  structure,  associated  with  OBJECT-TYPE  through  the  OBJECT- 
TYPE-AFFILIATION  relation  or  with  a  specific  OBJECT-ITEM  through  the 
OBJECT-ITEM-AFFILIATION  relation.  The  affiliation-category-code  values 
permit  representation  of  AFFILIATION-ETHNIC-GROUP,  AFFILIATION- 
FUNCTIONAL-GROUP,  AFFILIATION-GEOPOLITICAL,  and  AFFILIATION- 
RELIGION.  Extensive  lists  of  allowable  values  exist  for  ethnicity, 
geopolitical  and  religious,  function  is  limited  to:  Criminal,  Exercise, 
Multinational,  Terrorist,  Not  known,  or  Not  specified.  What  can’t  be 
obtained  from  these  attributes  is  whether  or  not  the  force  is  hostile. 
However,  each  OBJECT-ITEM  has  an  object-item-status-hostility-code 
attribute  (refer  to  the  section  on  Threat  Analysis). 

-Communications 

footprint 

NETWORK  is  a  particular  facility-category-code  attribute  value  for  FACILITY, 
which  is  a  selection  under  object-item-category-code  for  OBJECT-ITEM.  A 
communications  network  can  be  described  as  a  NETWORK  OBJECT-ITEM 
and  its  footprint  can  be  described  by  geometry  structures  in  LOCATION 
and  associated  to  the  OBJECT-ITEM  through  the  OBJECT-ITEM-LOCATION 
relation. 

-Equipment 

Described  by  type  in  OBJECT-TYPE/MATERIEL-TYPE/EQUIPMENT-TYPE  or 
individually  as  OBJECT-ITEM/MATERIEL.  The  HOLDING  relation  provides 
the  association  of  a  specific  object  (OBJECT-ITEM)  with  a  class  of  objects 
(OBJECT-TYPEs). 

-Nomenclature 

Attribute  equipment-type-id  for  EQUIPMENT-TYPE  in  OBJECT-TYPE  (object- 
type-category-code=MATERIEL-TYPE;  materiel-type-category- 
code=EQUIPMENT-TYPE).  By  individual  item,  OBJECT-ITEM  attributes 
object-item-name-text,  object-item-id,  materiel-id,  materiel-serial-number- 
identification-text,  materiel-lot-identification-text,  and  materiel-hull- 
number-text  provide  detailed  identification  of  an  item  of  equipment. 

-Type  of  equipment 

OBJECT-TYPE/EQUIPMENT-TYPE,  with  attributes  equipment-type-id  and 
equipment-type-category-code,  which  includes  ENGINEERING-EQUIPMENT- 
TYPE,  VEHICLE-TYPE  and  WEAPON-TYPE.  The  next  level  of  the  type 
structure  provides  additional  detailed  specification  of  type  through 
attributes  engineering-equipment-type-id  and  engineering-equipment-type- 
category-code  for  ENGINEERING-EQUIPMENT-TYPE,  vehicle-type-id  and 
vehicle-type-category-code  for  VEHICLE-TYPE,  and  weapon-type-id, 
weapon-type-category-code,  and  weapon-type-subcategory-code  for 
WEAPON-TYPE. 

-Quantity 

HOLDING  associates  OBJECT-TYPEs  (EQUIPMENT-TYPE)  with  an  OBJECT- 
ITEM  (e.g.,  a  unit),  providing  quantities  in  holding-operational-count  and 
holding-total-count  attributes. 
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Table  19  (cont.).  Association  of  M-COP  Forces  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Forces  Classes  and 
Attributes 

Corresponding  JC3IEDM  Entities  and  Attributes 

--Maintenance 
readiness  level 

Attribute  materiel-status-category-code  of  OBJECT-ITEM/OBJECT-ITEM- 
STATUS/MATERIEL-STATUS.  Materiel  can  suffer  mobility  damage  (materiel- 
status-operational-status-mode-code). 

--Weapons 

Type  described  in  OBJECT-TYPE/MATERIEL/EQUIPMENT/WEAPON-TYPE 
structure;  individual  item  in  OBJECT-ITEM/MATERIEL. 

—Fire  Support 
Assets 

Attribute  capability-subcategory-code  of  CAPABILITY  provides  information 
such  as  maximum  range,  sustained  fire  rate,  etc.  Additional  capability 
information  described  in  CAPABILITY/FIRE-CAPABILITY. 

--Vehicles 

Type  described  in  OBJECT-TYPE/MATERIEL/EQUIPMENT/VEHICLE-TYPE 
structure;  individual  item  in  OBJECT-ITEM/MATERIEL. 

—Mobility 

characteristics 

Attribute  capability-subcategory-code  of  CAPABILITY  provides  information 
such  as  maximum  speed  or  planning  speed  (with  designation  of  day  or 
night,  or  both,  capability).  Also  CAPABILITY/MOBILITY-CAPABILITY  specifies 
the  kind  of  mobility  (e.g.,  Air,  fixed  wing;  Air,  rotary  wing;  Amphibious; 
Dismounted;  Land,  tracked;  Land,  wheeled;  etc.)  and,  in  certain  cases,  the 
conditions  for  which  the  maneuver  capability  is  defined  (e.g.,  the  type  of 
terrain  that  is  being  traversed,  such  as  Cross-country;  Road;  Snow;  Terrain 
independent;  etc.).  JC3IEDM  needs  to  be  extended  to  include  the  detailed 
data  identified  in  the  NRMM/STNDMob  discussion  in  the  text. 

--Engineering 

Equipment 

Type  described  in  OBJECT-TYPE/MATERIEL/EQUIPMENT/ENGINEERING- 
EQUI PM  ENT-TYPE  structure  (with  attribute  engineering-equipment-type- 
category-code  with  values  including,  for  example,  Bridge  vehicle; 
Earthmover;  Mine  clearer;  Minefield  marking;  Tactical  floating  bridge); 
individual  item  in  OBJECT-ITEM/MATERIEL.  Attribute  capability- 
subcategory-code  of  CAPABILITY  provides  information  such  as  breaching 
time,  demolition  time,  etc.  Also,  additional  capabilities  are  described  in 
CAPABILITY/ENGINEERING-CAPABILITY. 

-Personnel 

PERSON-TYPE  in  OBJECT-TYPE;  individuals  are  identified  by  PERSON  in 
OBJECT-ITEM. 

-Quantity 

HOLDING  associates  OBJECT-TYPEs  (PERSON-TYPE)  with  an  OBJECT-ITEM 
(e.g.,  a  unit),  providing  quantities  in  holding-operational-count  and  holding- 
total-count  attributes. 

-Military 

Occupation 

Specialties 

NOT  PROVIDED  -  can  be  proposed  as  an  extension  to  the  JC3IEDM 
attributes  to  PERSON-TYPE  under  OBJECT-TYPE.  An  alternative  may  be  to 
use  the  CAPABILITY  structure,  where  CAPABILITY  is  defined  as  “The 
potential  ability  to  do  work,  perform  a  function  or  mission,  achieve  an 
objective,  or  provide  a  service.” 

-Experience  in  the 
area  of  operations 

NOT  PROVIDED— can  be  proposed  as  an  extension  to  the  JC3IEDM 
specification,  possibly  associated  with  particular  TASKs  associated  with  an 
individual  PERSON  (OBJECT-ITEM)  or  through  the  CAPABILITY  structure. 

-State  of  training 

Attribute  organization-status-training-code  of  ORGANISATION-STATUS 
under  OBJECT-ITEM-STATUS.  Can  also  relate  to  MISSION-CAPABILITY  (e.g., 
mission-capability-category-code  attribute  has  values  Air  assault;  Airborne; 
Civilian  law  enforcement;  Engineer,  combat;  Joint  intelligence;  medical 
evacuation;  etc.). 
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Table  19  (cont.).  Association  of  M-COP  Forces  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Forces  Classes  and 
Attributes 

Corresponding  JC3IEDM  Entities  and  Attributes 

-Fatigue 

NOT  SPECIFICALLY  PROVIDED— person-status-physical-status-code  has 
values  for  Fit;  Incapacitated,  not  walking;  Incapacitated,  walking;  Slightly 
incapacitated;  Not  known.  Also  the  person-status-physical-status-qualifier- 
code  with  values  for  Injured;  III,  Contagious;  Pregnant;  Wounded.  Can  be 
proposed  as  an  extension  to  JC3IEDM  values. 

-Supplies 

MATERIEL-TYPE/materiel-type-category-code=CONSUMABLE-MATERIEL- 
TYPE.  Subtypes  of  CONSUMABLE-MATERIEL-TYPE  distinguish  food,  fuel, 
water,  etc.  The  quantity  of  the  supply  type  in  a  unit  is  provided  in  the 
HOLDING  relation. 

-Capability  (including 

TTPs  and  mission 
packages) 

Represented  using  the  CAPABILITY  structure. 

-Support 

The  support  role  for  a  particular  operation  is  indicated  by  the  ACTION- 
OBJECTIVE-ITEM,  “a  battlespace  object  (FACILITY,  FEATURE,  MATERIEL, 
ORGANISATION,  or  PERSON)  which  is  the  focus  of  a  specific  ACTION.”  The 
desired  ACTION  is  defined  in  an  ACTION-TASK  to  be  performed.  The  unit 
providing  the  support  is  identified  in  the  ACTION/ACTION- 
RESOURCE/ACTION-RESOURCE-ITEM  structure. 

-Information 
requirements  (observer 
locations) 

Not  directly  provided,  but  described  in  the  JC3IEDM  specification  (Edition 
3.00)  under  the  section  titled  Intelligence  extension.  A  request  for 
intelligence  information  is  modeled  as  a  subtype  of  ACTION-TASK.  A 
response  to  a  request  for  intelligence  information  is  modeled  as  a 
REQUEST-ANSWER. 

-Force  structure 

Force  structures  are  described  by  OBJECT-ITEM-ASSOCIATIONs:  “Every 
instance  of  OBJECT-ITEM  can  have  some  type  of  relationship  to  another 
instance  of  OBJECT-ITEM  in  the  sense  of  belonging,  using,  controlling, 
being  constrained  by,  occupying  and  so  on.” 

-Bases 

OBJECT-ITEM/object-item-category-code=FACILITY. 

-Identification 

Provided  by  OBJECT-ITEM  object-item-id  attribute  or  the  FACILITY  facility-id 
or  facility-base-identification-code-text  attributes. 

-Location 

Refer  to  earlier  description  of  Location  above  (in  this  table). 

-Affiliation 

Refer  to  earlier  description  of  Affiliation  above  (in  this  table). 

-Control  measures 

As  a  type,  represented  in  OBJECT-TYPE/FEATURE-TYPE/CONTROL- 
FEATURE-TYPE  (includes  ROUTE-TYPE  for  specifying  movement  routes). 
Examples  of  CONTROL-FEATURE-TYPE  include  Airspace  coordination  area; 
Area  of  interest;  Area  of  responsibility;  Artillery  area;  Crossing  site; 

Decision  point;  Drop  zone;  Fire  support  coordination  line;  Forward  line  of 
troops;  Landing  zone;  ROUTE-TYPE;  Strong  point;  Supply  area;  etc.  Specific 
measures  are  described  by  OBJECT-ITEM/FEATURE/CONTROL-FEATURE, 
with  subtypes  for  APPROACH-DIRECTION,  ROUTE-SEGMENT,  AIRSPACE- 
CONTROL-MEANS,  and  ROUTE.  As  with  force  structures  described  above, 
control  measures  are  related  to  specific  forces  using  OBJECT-ITEM- 
ASSOCIATION.  The  full  set  of  Tactical  Graphics  (partitioned  into  Tasks, 
Command  and  Control  and  General  Maneuver,  Mobility/Survivability,  Fire 
Support,  Combat  Service  Support,  and  Other)  is  defined  in  MIL-STD- 
2525B. 
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Table  19  (cont.).  Association  of  M-COP  Forces  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Forces  Classes  and 
Attributes 

Corresponding  JC3IEDM  Entities  and  Attributes 

-Unit  boundaries 

Not  specifically  addressed,  but  readily  constructed  from  the  LOCATION 
geometry  and  FEATURE/CONTROL-FEATURE.  Can  be  added  to  the 
selections  for  CONTROL-FEATURE-TYPE,  together  with  any  other  control 
measures  that  are  deemed  necessary  for  explicit  representation  in 

JC3IEDM. 

-Adjacent  units’ 
dispositions 

Adjacent  units  can  be  identified  through  the  OBJECT-ITEM-ASSOCIATION 
relation.  Their  disposition  is  provided  through  the  data  identified  above  for 
forces  in  general. 

M-COP  Utilities  Category  Relationships  to  the  JC3IEDM 

Table  20  shows  a  comparison  between  the  M-COP  Utilities  category 
classes  and  the  JC3IEDM  representations. 


The  JC3IEDM  data  structure  LOCATION  is  the  overall  structure  for  speci¬ 
fying  location  and  geometry.  The  basic  element  is  a  point.  It  plays  a  role  in 
generating  every  other  geometric  construct  in  JC3IEDM.  All  geometric 
constructs  are  defined  either  totally  or  partially  in  terms  of  the  POINT 
structure.  Lines  are  generated  from  a  series  of  points  that  are  connected  in 
a  specified  order.  Surfaces  are  built  either  directly  from  lines  or  the  points 
provide  part  of  the  specification.  For  example,  a  polygon  area  is  defined  by 
a  closed  boundary  line.  There  is  some  alignment  between  JC3IEDM  and 
FEATURE  and  FEATURE_TOPOLOGY  is  included  under  JC3IEDM  entity 
LOCATION. 


The  JC3IEDM  does  not  contain  adequate  information  for  metadata 
entities  for  the  M-COP.  There  is  some  alignment  with  the  RESOURCE, 
SECURITY_CLASSIFICATION,  and  SOURCE  classes. 


The  M-COP  TIME  class  is  not  aligned  with  the  JC3IEDM,  which  does  not 
include  information  about  time  format. 
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Table  20.  Association  of  M-COP  Utilities  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Utility  Class 

Corresponding  JC3IEDM  Entity  or  Attribute 

DATA_QUALITY 

REPORTING-DATA  is  the  specification  of  source,  quality  and  timing  that 
applies  to  reported  data. 

reporting-data-accuracy-code 

reporting-data-credibility-code 

reporting-data-reliability-code 

OBJECT-ITEM-LOCATION  is  an  association  of  an  OBJECT-ITEM  with  a 
LOCATION  that  enables  the  geographic  position  of  the  OBJECT-ITEM  to  be 
specified.  The  operational  meaning  of  geometry  may  also  be  specified, 
object-item-location-horizontal-accuracy-dimension 
object-item-location-vertical-accuracy-dimension 

FEATURE 

Included  under  JC3IEDM  entity  LOCATION. 

FEATU  R  E_TO  PO  LOGY 

LINE-POINT  is  a  specification  of  one  of  an  ordered  sequence  of  POINTS 
used  to  define  the  specific  LINE. 

line-id 

line-point-index 

line-point-sequence-ordinal 

line-point-point-id 

FORMAT 

ACTION-OBJECTIVE-TYPE-IMAGERY-PRODUCT  is  the  intended 
characteristics  of  a  specific  ACTION-OBJECTIVE-TYPE-IMAGERY-PRODUCT 
that  is  an  instance  of  MATERIEL-TYPE. 

action-objective-type-imagery-product-image-type-code 

GEOMETRY 

In  JC3IEDM  the  entity  LOCATION  defines  all  locations  and  geometry.  The 
LOCATION  attribute  location-category-code  (point,  line,  surface,  or 
volume)  corresponds  to  M-COP’s  FEATURE  class. 

The  entity  POINT  is  a  zero  dimensional  LOCATION. 

point-category-code  (declares  either  absolute  of  relative  reference 
system) 

The  entity  LINE  is  defined  by  two  or  more  POINTS  connected  by  ID  line 
segments  used  to  define  specific  LINE. 

line-point-sequence-ordinal  (order  of  line  segments) 

The  entity  SURFACE  is  a  two-dimensional  LOCATION; 
surface-category-code  (ellipse,  polygon-area,  fan-area,  corridor-area,  etc.) 

The  LOCATION  entity  defines  all  of  M-COP’s  GEOMETRY  class  attributes 
and  names  the  attributes  in  the  FEATURE  class. 
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Table  20  (cont.).  Association  of  M-COP  Utilities  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Utility  Class 

Corresponding  JC3IEDM  Entity  or  Attribute 

LOCATION 

The  entity  LOCATION  is  a  specification  of  position  and  geometry  with 
respect  to  a  specified  horizontal  frame  of  reference  and  a  vertical 
distance  measured  from  a  specified  datum. 

location-id  is  an  attribute  of  both  LOCATION  and  OBJECT-ITEM- 
LOCATION 

location-category-code  (point,  line,  surface,  or  volume) 
corresponds  to  M-COP  FEATURE  and  GEOMETRY  classes 

OBJECT-REFERENCE  is  a  RELATIVE-COORDINATE-SYSTEM  that  has  its 
frame  of  reference  defined  by  using  the  position  and  orientation  of  a 
specific  OBJECT-ITEM  at  a  given  point  in  time. 

POINT-REFERENCE  is  a  RELATIVE-COORDINATE-SYSTEM  that  uses  three 
specific  POINTS  to  establish  its  frame  of  reference. 

RELATIVE-COORDINATE-SYSTEM  is  a  rectangular  frame  of  reference 
defined  by  an  origin,  x  and  y  axes  in  the  horizontal  plane,  and  a  z-axis. 

RESOURCE 

REFERENCE  is  the  identification  of  a  record  of  information, 
reference-approval-datetime 
reference-content-category-code 
reference-creation-datetime 
reference-description-text 
reference-electronic-source-text 
referen  ce-f  i  1  e-size-q  ua  ntity 
reference-format-text 
reference-language-code 
reference-lifecycle-code 
reference-medium-type-code 
reference-originator-text 
reference-physical-size-text 
reference-primary-location-text 
reference-publication-datetime 
ref  e  re  n  ce-re  1  easa  b  i  1  ity-text 
reference-security-classification-code 
ref  e  re  n  ce-s  h  o  rt-t  i  tl  e-text 
reference-title-text 
reference-transmittal-type-code 
reference-validity-period-begin-datetime 
reference-validity-period-end-datetime 
reference-verification-code 
reference-version-text 

ORGANISATION  is  an  OBJECT-ITEM  that  is  an  administrative  or  functional 
structure. 

ORGANISATION-ACTION-ASSOCIATION  is  a  relationship  indicating  the  role 
of  a  specific  ORGANISATION  with  respect  to  a  specific  ACTION. 

ORGANISATION-TYPE  is  an  OBJECT-TYPE  that  represents  administrative 
or  functional  structures. 

organisation-type-category-code 

organisation-type-description-text 

ERDC  TR-07-4 


81 


Table  20  (cont.).  Association  of  M-COP  Utilities  category  with  JC3IEDM  entities  and  attributes. 


M-COP  Utility  Class 

Corresponding  JC3IEDM  Entity  or  Attribute 

ADDRESS 

address-category-code  (electronic  or  physical) 
address-place-nam  e-text 

RESOURCE 

(continued) 

PHYSICAL-ADDRESS 

physical-add  ress-catego  ry-cod  e 
physical-address-residence-text 
physical-address-street-text 
physical-address-street-additional-text 
physical-address-postal-box-text 
physical-address-postbox-identifier-text 
p  hys  i  ca  l-a  d  d  ress-c  ity-text 
physical-address-geographic-text 
physi  ca  l-ad  d  ress-posta  l-cod  e-text 

SECURITY_CLASSIFICATION 

CONTEXT  is  a  collection  of  information  that  provides  in  its  entirety  the 
circumstances,  conditions,  environment,  or  perspective  for  a  situation, 
security-classification-code  is  the  specific  value  that  represents 
the  level  of  NATO  security  classification,  (cosmic  top  secret,  NATO 
confidential,  NATO  restricted,  NATO  secret,  NATO  unclassified) 

REFERENCE  identifies  a  record  of  information. 

reference-security-classification-code  is  the  specific  value  that 
represents  the  security  classification  of  the  artifact  cited  in  a 
specific  REFERENCE. 

REPORTING-DATA 

reporti  ng-d  ata-rel  ia  bi  1  ity-code 
reporting-data-reporting-organisation-id 
reporti  ng-d  ata-reporti  ng-d  ateti  me 

SOURCE 

REPORTING-DATA-ABSOLUTE-TIMING 

reporti  ng-d  ata-a  bsol  ute-ti  m  i  ng-effecti  ve-sta  rt-dateti  me 
reporting-data-absolute-timing-effective-end-datetime 

REPORTI  NG-DATA-RELATIVE-TIMING 

reporting-data-relative-timing-offset-duration 

reporting-data-relative-timing-reference-action-task-id 

SUMMARY_CONTENT 

Similar  to  SOURCE  and  RESOURCE. 

TIME 

The  information  needed  for  M-COP  is  not  found  in  JC3IEDM. 

ACTION-TASK 

action-task-planned-end-datetime 

action-task-planned-start-datetime 

USAGE 

CONTEXT-ASSESSMENT 

context-assessment-effective-datetime 

ACTION-CONTEXT-STATUS  is  a  point  in  time  that  designates  the  beginning 
of  the  period  of  effectiveness 

a  ct  i  on  -co  ntext-statu  s-ef  fecti  ve-d  atet  i  m  e 
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Summary  of  M-COP  Category  Relationships  to  the  JC3IEDM 

Terrain  Category 

Most  of  the  M-COP  required  terrain  features  and  facilities  are  found  in  the 
JC3IEDM,  and  it  appears  that  those  missing  could  easily  be  added  as 
JC3IEDM  geographic-feature-type-category-codes  or  facility-category- 
codes.  What  is  more  significant  is  the  lack  of  detail  in  the  attributes  associ¬ 
ated  with  these  JC3IEDM  OBJECT-ITEMs  (FEATURE  and  FACILITY), 
and  which  are  required  for  the  M-COP.  The  addition  of  some  of  the  M- 
COP  Terrain  subclasses  (TRAFFICABILITY_SURFACE,  _VEGETATION, 
and  _WETGAPS,  and  _DRYGAPS)  to  the  JC3IEDM  as  additional  STATUS 
entities  seems  straightforward.  Adding  attribution  associated  with  the  M- 
COP  Terrain  ROAD  class  will  take  some  careful  analysis  and  merging  with 
existing  J3CIEDM  attributes. 

Obstacle  Category 

While  most  of  the  M-COP  Obstacle  category  classes  can  be  found  in  the 
JC3IEDM,  they  lack  sufficient  attribution  to  meet  the  needs  of  the  M-COP. 
Each  Obstacle  will  need  to  have  a  set  of  attributes  developed  within  the 
JC3IEDM,  similar  to  what  is  available  for  LANDMINES,  the  attributes  of 
which  also  need  to  be  enhanced  or  merged  with  M-COP  attributes  and 
allowable  values. 

Weather  Category 

There  is  good  alignment  between  the  M-COP  classes  and  the  JC3IEDM 
entity  METEOROLOGIC-FEATURE.  In  the  case  of  the  M-COP  Weather 
classes  ATMOSPHERE,  PRECIPITATION,  CLOUD_COVER,  ICING, 
LIGHTING_AND_VISIBILITY,  and  WIND,  not  all  of  the  M-COP  attrib¬ 
utes  map  to  JC3IEDM. 

Maneuver  Analysis  Category 

While  the  JC3IEDM  offers  much  of  the  context  required  for  doing  maneu¬ 
ver  analysis,  significant  gaps  exist.  The  missing  attributes,  for  the  most 
part,  are  related  to  analysis  of  maneuver/trafficablity,  tasks  typically  done 
during  terrain  analysis,  and  the  generation  of  the  graphical  control  meas¬ 


ures. 
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Route  Finding  Category 

JC3IEDM  does  not  represent  route  finding  well.  However,  three  changes 
to  JC3IEDM  would  accommodate  most  Route  Finding  information.  The 
changes  include  addition  of  a  mathematical  GRAPH  construct,  representa¬ 
tion  of  General  Vehicle  Types,  and  addition  of  constructs  to  represent  the 
M-COP  Route  Finding  category  class  CONSTRAINTS  for  the  route  being 
sought. 

Threat  Analysis  Category 

The  analysis  done  for  this  report  showed  that  the  M-COP  Threat  Analysis 
category  is  represented  in  JC3IEDM.  Some  information,  related  to  threat, 
is  in  the  Forces  Category  and  discussed  there. 

Forces  Category 

Most  of  the  information  required  for  the  M-COP  is  found  in  the  current 
specification  of  the  JC3IEDM.  The  key  information  that  needs  to  be  added 
is  more  complete  technical  data  for  vehicles  as  provided  in  the  NRMM  and 
STNDMob  API. 

Utilities  Category 

The  JC3IEDM  contains  adequate  information  for  the  M-COP  Utilities 
category  classes  FEATURE  and  GEOMETRY.  There  are  insufficient  data 
structures  for  FEATURE_TOPOLOGY.  The  JC3IEDM  does  not  contain 
adequate  information  for  metadata  entities  for  the  M-COP.  The  key  infor¬ 
mation  for  M-COP  is  found  in  the  DMMS.  There  is  some  alignment  in  the 
JC3IEDM  with  the  M-COP  RESOURCE,  SECURITY_CLASSIFICATION, 
and  SOURCE  classes. 
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7  M-COP  WEB  ONTOLOGY  LANGUAGE  (OWL) 
IMPLEMENTATION 

The  second  interim  report  (Blais  et  al.  2005b)  discussed  the  development 
and  design  of  a  preliminary  ontology  for  M-COP.  Here,  we  further  present 
the  M-COP  ontology  by  expressing  a  preliminary  version  using  the  Protege 
ontology  editing  tool  provided  by  Stanford  University.*  This  editing  tool 
allows  us  to  define  classes,  subclasses,  and  properties  as  OWL  expressions. 
Figure  8  shows  (partially)  the  relationships  between  the  Terrain  category 
(Table  4)  and  its  classes  and  subclasses,  along  with  some  classes  of  Route 
Finding.  The  arrows  connecting  elements  can  be  read  as  “is  a”  relation¬ 
ships  in  a  left-to-right  manner  (e.g.,  an  area  “is  a”  geometry).  The  darker- 
colored  classes  indicate  that  they  are  defined  by  properties  relating  them 
to  other  classes  (for  example,  terrain  must  have  a  geometry).  These  types 
of  relationships  between  classes  are  relatively  easy  to  define;  what 
becomes  difficult  is  defining  relationships  that  require  computations 
(those  relationships  that  were  recognized  as  services  in  Figure  2).  The 
challenge  is  to  develop  classes,  subclasses,  and  properties  within  the  ontol¬ 
ogy  that  can  be  instantiated,  based  on  a  service,  and  also  based  on  as  much 
knowledge  that  can  be  “built-in”  to  the  ontology  as  possible. 

The  M-COP  ontology  design  and  development  work  remains  very  prelimi¬ 
nary  at  this  time.  However,  ontology  development  work  is  ongoing  in  a 
number  of  related  areas,  including  the  synthetic  environment  (Bhatt  et  al. 
2004)  and  plans  and  orders  (Blais  et  al.  2006),  that  can  be  leveraged  for 
M-COP  ontology  development. 


*  http://protege.stanford.edu 
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Figure  8.  Segment  of  the  M-COP  ontology  showing  partially  the  Route  Finding,  Obstacles,  and 
Terrain  categories. 
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8  LESSONS  LEARNED 

In  the  course  of  this  effort,  it  was  disappointing  to  find  so  few  fully  speci¬ 
fied,  application-independent  components  that  would  serve  the  needs  of 
the  M-COP  model.  This  forced  the  team  to  work  with  more  primitive  (as  in 
“weaker  semantics”  as  identified  in  Figure  2)  data  structures  than  was 
anticipated  at  the  outset.  While  constraining  the  achievement  of  some  of 
the  original  goals  of  the  effort,  this  lack  of  formal  models  in  itself  was  an 
important  finding,  resulting  in  a  comprehensive  effort  to  identify  and 
define  necessary  ground  vehicle  mobility  data  to  support  movement  plan¬ 
ning.  The  resulting  model  description  in  this  report  is  perhaps  less  encum¬ 
bered  by  pre-existing  biases. 

As  stated  previously,  it  was  not  the  intent  of  this  project  to  develop  a  for¬ 
mal  data  model,  though  we  found  ourselves  drawn  in  that  direction,  as  we 
tried  to  understand  existing  data  models,  system  data  representations,  and 
potential  applications.  The  lack  of  specific  target  applications,  while  keep¬ 
ing  us  from  a  point-to-point  solution  or  multiple-point  solutions,  also  kept 
us  from  a  definitive  M-COP  solution. 

While  numerous  methods  of  storing  a  data  model  exist  (Microsoft  Access, 
Oracle,  MySQL),  these  in  themselves  become  an  application,  so  we  settled 
on  MS  Word  document  tables,  which  are  easy  to  examine,  but  difficult  to 
cross  check  for  consistency  across  tables,  and  nor  can  they  be  considered 
an  implementation.  The  use  of  Protege  for  the  development  of  a  M-COP 
ontology  appears  promising,  but  linking  relationships  that  require  com¬ 
plex  computations  appears  problematic. 
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9  RECOMMENDATIONS  FOR  FUTURE  WORK 

•  For  broadest  applicability  of  the  M-COP  representation,  we  recom¬ 
mend  establishing  a  Working  Group  to  fully  specify  the  M-COP 
information  model  in  the  context  of  the  JC3IEDM.  This  is  being  done 
in  other  critical  data  modeling  areas,  such  as  for  exchange  of  Chemical, 
Biological,  Radiological,  and  Nuclear  (CBRN)  data  (Johnson  2004; 
Johnson  and  Vachher  2005).  It  would  become  the  responsibility  of  the 
Working  Group  to  evaluate  the  JC3IEDM,  with  existing  and  planned 
extensions,  to  specify  M-COP  information  requirements  in  that  context 
and  to  prepare  necessary  proposals  for  extensions  to  JC3IEDM  to 
provide  required  M-COP  data. 

•  Working  through  the  JC3IEDM  also  provides  a  path  toward  stronger 
semantic  representations  as  various  initiatives  arise  to  create  a  formal 
ontology  of  command  and  control  information.*  We  recommend  that 
personnel  familiar  with  M-COP  objectives  and  the  current  M-COP 
representation  participate  in  such  efforts  to  ensure  that  ground  vehicle 
mobility  information  is  fully  characterized,  particularly  in  areas  where 
significant  reasoning  is  currently  hidden  in  software  rather  than 
exposed  through  data,  such  as  for  maneuver  analysis,  terrain  reason¬ 
ing,  threat  analysis,  route  finding,  and  identification  of  obstacles  that 
can  impede  movement.  Some  relevant  references  to  this  type  of  work 
follow: 

o  An  evaluation  of  the  C2IEDM  as  an  ontology: 

http://www.vmasc.odu.edu/pubs/tolk-evaluationoi.pdf 

o  OWL  ontology  for  a  subset  of  C2IEDM: 

http://www.d0dccrp.0rg/events/2005/10th/papers/239.pdf 

o  (Blais  et  al.,  2005d)  SISO  Study  Group  Report  on  C-BML  and 
C2IEDM: 

http://www.movesinstitute.org/~blais/CoalitionBMLStudyGroup. 

htm 

o  Ontologies  on  top  of  C2IEDM: 

http://discussions.sisostds.org/default.asp?action=9&fid= 

46&read=3835i 


*  There  has  been  interest  expressed  in  the  Modeling,  Simulation  and  Demonstration  (MSD)  Working 
Group  of  the  Network  Centric  Operations  Industry  Consortium  (http://www.NCOIC.org)  to  initiate  an  effort 
to  develop  an  ontology  formalization  of  the  JC3IEDM. 


including  the  Suggested  Upper  Merged  Ontology  (SUMO)  and 
http://ontology.teknowledge.com/arch.html 

An  FCA  of  the  M-COP  data  model  should  be  conducted  as  a  metric  to 
assess  appropriateness  of  the  model.  As  the  model  is  refined,  the  initial 
FCA  can  be  used  to  guide  improvements. 

The  M-COP  ontology  should  be  developed  further  and  submitted  to  the 
DOD  Metadata  Registry  and  Clearinghouse  for  review  and  feedback. 

The  NRMM  and  STNDMob  API  XML  schema  and  data  files  should  be 
assigned  to  an  appropriate  XML  Namespace  and  submitted  to  the  DOD 
Metadata  Registry  and  Clearinghouse  for  broad  re-use. 

The  STNDMob  API  should  be  configured  to  operate  as  a  Web  service 
and  offered  for  use  in  the  Defense  Information  Systems  Agency  (DISA) 
GIG  prototype  efforts. 

As  part  of  an  effort  by  a  related  ERDC  project,  Common  Maneuver 
Networks  for  Embedded  Training,  Mission  Planning  and  Rehearsal,  a 
demonstration  service  should  be  developed.  This  would  explore  the  use 
of  the  M-COP  service  descriptions  and  emerging  ontology  with  OOS  as 
a  route-finding  client  and  BTRA  maneuver  network  products  serving  as 
a  basis  for  routing  calculations.  The  routing  will  initially  require  way- 
points  and  vehicle  types  as  input,  but  should  be  extended,  where  possi¬ 
ble,  to  include  OOS  entity  behavior  needs  as  routing  constraints. 
Results  from  this  work  will  inform  further  refinement  of  M-COP 
service  description  and  continued  development  of  the  M-COP  taxon¬ 
omy.  Figure  9  depicts  the  demonstration  concept. 
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Figure  9.  Demonstration  application  of  M-COP  Web  Services. 
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10  SUMMARY 

The  amount  of  information  to  represent  ground  vehicle  mobility  and 
maneuver  at  a  high  level  of  fidelity  is  voluminous,  particularly  in  the  area 
of  terrain  attribution.  The  linkages  and  analysis  required  between  terrain 
information  and  maneuver  performance  can  be  complex;  however,  by 
identifying  these  requirements  we  have  taken  the  first  step  to  achieve  an 
M-COP  for  BC  and  M&S.  For  the  first  time,  a  body  of  knowledge  is  speci¬ 
fied  for  this  domain  that  indicates  both  the  raw  data  necessary  for  move¬ 
ment  planning  as  well  as  the  logic  products  needed  to  support  movement 
planning  through  software  services  or  as  decision  support  tools. 

The  M-COP  data  model  as  presented  here  can  neither  be  called  a  definitive 
work  nor  a  complete  work.  It  is,  however,  one  of  the  “80%  solutions”  that 
are  critical  to  advances  in  military  technology  and  capability.  Taking  the 
lead  from  the  long-standing,  practical,  multi-national,  multi-service 
C2IEDM/JC3IEDM  development,  this  M-COP  data  model  provides  a  core 
set  of  information  requirements  for  ground  vehicle  mobility  that  can  be 
extended  and  refined  as  the  concepts  are  employed. 
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ACRONYMS 


A2C2 

AA 

ABCS 

ABE 

AM  SO 

AO 

API 

APOD 

AUTL 

BC 

BCSE 

BFT 

BML 

BN 

BOS 

BTRA 

C2 

C4I 

C2IEDM 

C-BML 

CBRN 

CES 

C/JMTK 

CIO 

COA 


Army  Airspace  Command  and  Control 
Avenues  of  Approach 
Army  Battle  Command  System 
Army  Battlespace  Environment 
Army  Modeling  and  Simulation  Office 
Area  of  Operations 
Application  Program  Interface 
Aerial  Port  of  Debarkation 
Army  Universal  Task  List 
Battle  Command 

Battle  Command  Simulation  and  Experimentation 

Blue  Force  Tracker 

Battle  Management  Language 

Battalion 

Battlefield  Operating  Systems 
Battlespace  Terrain  Reasoning  and  Analysis 
Command  and  Control 

Command,  Control,  Communications,  Computers, 
and  Intelligence 

Command  and  Control  Information  Exchange  Data 
Model 

Coalition  Battle  Management  Language 

Chemical,  Biological,  Radiological,  and  Nuclear 

Core  Enterprise  Services 

Commercial  Joint  Mapping  Toolkit 

Chief  Information  Officer 

Course  of  Action 
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COI 

COP 

CP 

CROM 

CS 

CSS 

DCS 

DDMS 

DFAD 

DIS 

DISA 

DNS 

DS 

EA 

ECS 

EDCS 

EDM-AOS 

ERDC 

FACC 

FBCB2 

FCA 

FFIR 

FM 

FOC 

GCC 

GDC 

GeoBML 

GIG 

GML 


Community  of  Interest 
Common  Operational  Picture 
Checkpoint 

C4I-M&S  Reference  Object  Model 

Combat  Support 

Combat  Service  Support 

Deputy  Chief  of  Staff 

DOD  Discovery  Metadata  Specification 

Digital  Feature  Analysis  Data 

Distributed  Interactive  Simulation 

Defense  Information  Systems  Agency 

Domain  Name  System 

Direct  Support 

Engagement  Areas 

Environment  Control  Service 

Environmental  Data  Coding  Specification 

Environmental  Data  Model— Atmosphere  Ocean  and 
Space 

Engineer  Research  and  Development  Center 

Feature  and  Attribute  Coding  Catalog 

Force  XXI  Battle  Command  Brigade  and  Below 

Formal  Concepts  Analysis 

Friendly  Forces  Information  Requirements 

Frequency  Modulation 

Force  Operating  Capabilities 

Geocentric  Coordinates 

Geodetic  Coordinates 

Geospatial  Battle  Management  Language 

Global  Information  Grid 

OpenGIS  Geography  Markup  Language 
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GS 

GS-R 

HET 

HTTP 

HQ 

IED 

IMETS 

IPB 

JC2 

JC3IEDM 

JDAM 

JMCDM 

LOS 

M2M 

M&S 

M-COP 

MC 

MCOO 

MEDEVAC 

METOC 

MGRS 

MIP 

MLC 

MOOTW 

MSD 

MSDL 

NATO 

NCOIC 

NCOWRM 


General  Support 
General  Support  -  Reinforcing 
Heavy  Equipment  Transporter 
Hyper  Text  Transfer  Protocol 
Headquarters 

Improvised  Explosive  Device 

Integrated  Meteorological  System 

Intelligence  Preparation  of  the  Battlefield 

Joint  Command  and  Control 

Joint  Consultation,  Command,  and  Control 
Information  Exchange  Data  Model 

Joint  Direct  Attack  Munition 

Joint  METOC  Conceptual  Data  Model 

Line  of  Sight 

Machine-to-Machine  Messaging 
Modeling  and  Simulation 
Mobility  Common  Operational  Picture 
Mobility  Corridors 

Modified  Combined  Obstacle  Overlay 

Medical  Evacuation 

Meteorology  and  Oceanography 

Military  Grid  Reference  System 

Multilateral  Interoperability  Programme 

Military  Load  Class 

Military  Operations  Other  Than  War 

Modeling,  Simulation,  and  Demonstration 

Military  Scenario  Definition  Language 

North  Atlantic  Treaty  Organization 

Network  Centric  Operations  Industry  Consortium 

Net-Centric  Operations  and  Warfare  Reference  Model 
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NRMM 

OOS 

OOS  EDM 
OP 

OPORD 

OWL 

OWL-S 

RS 

SAP 

SASO 

SEDRIS 

SEMP 

SISO 

SIW 

SME 

SMTP 

SOA 

SOAP 

SPOD 

STNDMob 

SUMO 

TEC 

TPL 

TIP 

TRADOC 
UML 
UOB  DAT 
UTM 
UUID 


NATO  Reference  Mobility  Model 
OneSAF  Objective  System 

OneSAF  Objective  System  Environmental  Data  Model 

Observation  Post 

Operations  Order 

Web  Ontology  Language 

Web  Ontology  Language  for  Services 

Regimental  Support 

Semi- Automated  Force 

Stability  and  Support  Operations 

Synthetic  Environment  Data  Representation  and 
Interchange  Specification 

Systems  Engineering  Management  Process 

Simulation  Interoperability  Standards  Organization 

Simulation  Interoperability  Workshop 

Subject  Matter  Expert 

Simple  Mail  Transfer  Protocol 

Service-Oriented  Architecture 

Simple  Object  Access  Protocol 

Seaport  of  Debarkation 

Standard  Mobility 

Suggested  Upper  Merged  Ontology 

Topographic  Engineering  Center 

Time  Phase  Lines 

Tactics,  Techniques,  and  Procedures 
US  Army  Training  and  Doctrine  Command 
Unified  Modeling  Language 
Unit  Order  of  Battle  Data  Access  Tool 
Universal  Transverse  Mercator 
Universal  Unique  Identifier 
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uxo 

Unexploded  Ordnance 

VOT 

Visual  Object  Taxonomy 

WSDL 

Web  Services  Description  Language 

XML 

Extensible  Markup  Language 

XSL 

Extensible  Stylesheet  Language 
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GLOSSARY 


Term 

Definition 

Army  Universal  Task  List  (AUTL) 

The  AUTL  provides  a  common,  doctrinal  structure  for  collective  tasks 
that  support  Army  tactical  missions  and  operations  performed  by  Army 
units  and  staffs.  Articulates  what  tasks  the  Army  performs  to 
accomplish  missions. 

Attribute 

A  property  or  characteristic  that  is  common  to  some  or  all  of  the 
instances  of  an  entity.  An  attribute  represents  the  use  of  a  domain  in 
the  context  of  an  entity. 

Battle  Management  Language 
(BML) 

The  unambiguous  language  used  to:  1)  command  and  control  forces 
and  equipment  conducting  military  operations  and,  2)  provide  for 
situational  awareness  and  a  shared,  common  operational  picture.  It  can 
be  seen  as  a  representation  of  a  digitized  commander’s  intent  to  be 
used  for  real  troops,  for  simulated  troops,  and  for  future  robotic  forces. 

Battlefield  Operating  System  (BOS) 

The  BOS  are  the  physical  means  (soldiers,  organizations,  and 
equipment)  that  commanders  use  to  accomplish  missions. 

Cardinality 

The  number  of  entity  instances  that  can  be  associated  with  each  other 
in  a  relationship. 

Class 

A  class  defines  a  group  of  individuals  that  belong  together  because  they 
share  some  properties. 

Coalition  Battle  Management 
Language  (C-BML) 

Unambiguous  language  to  describe  commander’s  intent,  to  be 
understood  by  both  live  forces  and  automated  systems,  for  simulated 
and  real  world  operations. 

Command  and  Control  Information 
Exchange  Data  Model  (C2IEDM) 

A  data  model  that  is  managed  by  the  Multilateral  Interoperability 
Programme  (MIP).  The  C2IEDM  serves  as  a  common  baseline  for 
information  exchange  that  is  designed  to  support  common,  or  generic, 
information  exchange  terms. 

Core  Enterprise  Services  (CES) 

Generic  information  services  that  apply  to  any  COI,  provide  the  basic 
ability  to  search  the  enterprise  for  desired  information,  and  then 
establish  a  connection  to  the  desired  service. 

Database 

A  collection  of  interrelated  data,  often  with  controlled  redundancy, 
organized  according  to  a  schema  to  serve  one  or  more  applications. 

Data  model 

A  graphical  and  textual  representation  of  analysis  that  identifies  the 
data  needed  by  an  organization  to  achieve  its  mission,  functions,  goals, 
objectives,  and  strategies  and  to  manage  and  rate  the  organization.  A 
data  model  identifies  the  entities,  domains  (attributes),  and 
relationships  (or  associations)  with  other  data,  and  provides  the 
conceptual  view  of  the  data  and  the  relationships  among  data. 

Data  type 

A  categorization  of  an  abstract  set  of  possible  values,  characteristics, 
and  set  of  operations  for  an  attribute.  Integers,  real  numbers,  character 
strings,  and  enumerations  are  examples  of  data  types. 
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Term 

Definition 

Defense  Discovery  Metadata 
Specification  (DDMS) 

Defines  discovery  metadata  elements  for  resources  posted  to 
community  and  organizational  shared  spaces. 

Edge 

A  connection  between  two  vertices  or  nodes 

Entity 

The  representation  of  a  set  of  real  or  abstract  things  (people,  objects, 
places,  events,  ideas,  combination  of  things,  etc.)  that  are  recognized 
as  the  same  type  because  they  share  the  same  characteristics  and  can 
participate  in  the  same  relationships. 

Entity  Relationship  Diagram 

An  ER  diagram  represents  graphically  a  list  of  entity  types,  the 
permissible  relations  between  them,  and  some  of  the  constraints  on 
those  relations. 

Environment  Data  Coding  Standard 
(EDCS) 

Stand  alone  data  coding  standard  that  characterizes  environmental 
objects  according  to  their  semantic  identification. 

Extensible  Markup  Language  (XML) 

A  general-purpose  markup  language  for  creating  special-purpose 
markup  languages,  capable  of  describing  many  different  kinds  of  data. 

Its  primary  purpose  is  to  facilitate  the  sharing  of  data  across  different 
systems.  (http://www.w3.org/TR/REC-xml/) 

Extensible  Stylesheet  Language 
(XSL) 

A  set  of  language  technologies  for  defining  XML  document 
transformation  and  presentation. 

Formal  Concept  Analysis  (FCA) 

A  theory  of  data  analysis  that  identifies  conceptual  structures  among 
data  sets.  These  structures  can  be  graphically  represented  as 
conceptual  hierarchies,  allowing  the  analysis  of  complex  structures  and 
the  discovery  of  dependencies  within  the  data.  FCA  is  increasingly 
applied  in  conceptual  clustering,  data  analysis,  information  retrieval, 
knowledge  discovery,  and  ontology  engineering. 

GeoBML 

GeoBML  is  an  extension  of  BML  into  the  domain  of  actionable 
geospatial  information;  provides  a  semantic  and  syntactic  bridge 
between  the  Warfighter's  decision  making  and  situational  awareness 
needs  and  the  terrain  experts'  realm.  It  is  NOT  a  geo-spatial  database. 

Geography  Markup  Language 
(GML) 

OpenGIS  Consortium  specification  that  provides  objects  for  describing 
geography  including  features,  coordinate  reference  systems,  geometry, 
topology,  time,  unit  of  measure,  and  generalized  values. 

Global  Information  Grid  (GIG) 

The  globally  interconnected,  end-to-end  set  of  information  capabilities, 
associated  processes,  and  personnel  for  collecting,  processing,  storing, 
disseminating,  and  managing  information  on  demand  to  warfighters, 
policymakers,  and  support  personnel.  The  GIG  includes  all  owned  and 
leased  communications  and  computing  systems  and  services,  software 
(including  applications),  system  data,  security  services,  and  other 
associated  services  necessary  to  achieve  information  superiority  for  the 
U.S.  military.  It  is  the  physical  manifestation  of  the  network-centric 
warfare  doctrine. 

Instance 

One  of  a  set  of  real  or  abstract  things  represented  by  an  entity. 

Joint  Consultation,  Command,  and 
Control  Information  Exchange  Data 
Model  (JC3IEDM) 

An  information  exchange  data  model.  The  next  version  of  C2IEDM.  This 
data  model  extends  and  enhances  the  C2IEDM  in  a  consistent  manner 
and  will  support  XML  information  exchanged. 

Joint  METOC  Broker  Language 
(JMBL) 

The  JMBL  schema  provides  an  XML  representation  of  the  JMCDM  and 
establishes  a  single  interface  for  requesting  and  retrieving  METOC  data. 
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Term 

Definition 

Joint  METOC  Conceptual  Data 

Model  (JMCDM) 

JMCDM,  a  logical  data  model,  was  created  in  1995  to  integrate  the 
geophysical  data  requirements  of  all  DOD  components.  JMCDM  and  its 
supporting  encyclopedia  are  a  subset  of  the  DOD  Enterprise  Data 

Model. 

M-COP 

The  definition  set  by  this  team  is  “A  subset  of  the  COP  consisting  of 
relevant  movement  and  maneuver  data  and  information  shared  by 
more  than  one  command.  The  M-COP  can  be  tailored  for  various  users 
and  will  include  data  and  information  for  mobility  of  individual 
combatants,  ground  vehicles,  and  autonomous/ robotic  vehicles." 

Markup  language 

A  markup  language  combines  text  and  extra  information  about  the  text. 
The  extra  information,  for  example  about  the  text's  structure  or 
presentation,  is  expressed  using  markup,  which  is  intermingled  with  the 
primary  text. 

Military  Scenario  Definition 

Language  (MSDL) 

An  XML  based  data  interchange  format  that  enables  02  planning 
applications  to  interchange  the  military  portions  of  scenarios  with 
simulations  and  other  applications. 

Ontology 

An  explicit,  formal,  machine-readable  semantic  model  defining  the 
classes  (or  concepts)  and  their  possible  inter-relations  pertinent  to  a 
specific  domain. 

Web  Ontology  Language  (OWL) 

A  markup  language  for  publishing  and  sharing  data  using  ontologies  on 
the  Internet.  (http://www.w3.org/TR/owl-features/) 

Web  Ontology  Language  for 

Services  (OWL-S) 

OWL-S  is  an  OWL-based  Web  service  ontology,  which  supplies  Web 
service  providers  with  a  core  set  of  markup  language  constructs  for 
describing  the  properties  and  capabilities  of  their  Web  services  in 
unambiguous,  computer-interpretable  form.  OWL-S  markup  of  Web 
services  will  facilitate  the  automation  of  Web  service  tasks,  including 
automated  Web  service  discovery,  execution,  composition,  and 
interoperation. 

Reasoner 

Software  tool  that  can  derive  new  formally  annotated  facts  from  a  set  of 
predefined  formally  annotated  facts. 

Relationship 

An  association  between  two  entities  or  between  instances  of  the  same 
entity. 

Semantics 

The  meaning  of  the  syntactic  components  of  a  language. 

Semantic  Web 

A  project  that  intends  to  create  a  universal  medium  for  information 
exchange  by  putting  documents  with  computer-processable  meaning 
(semantics)  on  the  World  Wide  Web.  The  Semantic  Web  comprises  the 
standards  and  tools  of  XML,  XML  Schema,  RDF,  RDF  Schema  and  OWL. 

Service 

A  service  is  an  abstract  resource  that  represents  a  capability  of 
performing  tasks  that  form  a  coherent  functionality  from  the  point  of 
view  of  providers’  entities  and  requesters’  entities.  To  be  used,  a  service 
must  be  realized  by  a  concrete  provider  agent. 

Service-Oriented  Architecture  (SOA) 

A  paradigm  for  organizing  and  utilizing  distributed  capabilities  that  may 
be  under  the  control  of  different  ownership  domains.  It  provides  a 
uniform  means  to  offer,  discover,  interact  with,  and  use  capabilities  to 
produce  desired  effects  consistent  with  measurable  preconditions  and 
expectations. 
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Term 

Definition 

Simple  Object  Access  Protocol 
(SOAP) 

A  protocol  for  exchanging  XML-based  messages  over  a  computer 
network,  normally  using  HTTP.  SOAP  forms  the  foundation  layer  of  the 
Web  services  stack,  providing  a  basic  messaging  framework  upon  which 
more  abstract  layers  can  build. 

Web  Services  Description 

Language  (WSDL) 

An  XML-based  service  description  on  howto  communicate  using  the 
web  service,  namely,  the  protocol  bindings  and  message  formats 
required  to  interact  with  the  web  services  listed  in  its  directory. 
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APPENDIX  A:  M-COP  TERRAIN  CATEGORY 

Tables  A1-A6  present  the  enumeration  values  for  a  Feature__Type  attrib¬ 
ute  of  each  of  the  Terrain  classes.  These  enumeration  values  are  the  same 
as  their  sources.  For  reader  ease,  the  formats  have  been  changed  to  the 
nomenclature  chosen  for  this  report.  The  intent  for  the  M-COP  is  to  use 
the  OOS  EDM  values;  the  other  sources  are  shown  only  for  comparison. 
The  terms  area,  line,  directed_line,  3d__line,  and  point  denote  the 
geometry  type. 

Table  Al.  Enumeration  values  for  Feature_Type  attribute,  Terrain  class  NATURAL_REGION. 


JC3IEDM  geographic  or 
facility  category  code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

alkali_flats 

animal_sanctuary 

asphaltjake  area 

asphaltjake 

asphaltjake 

barrier  area 

X 

bog  area 

bog,  marsh,  marsh_or_swamp,  swamp 

marsh,  swamp, 

coastal_marshJn_nontidal_waters, 
coastal_marshJnJidal_waters, 
cranberry_bog,  peat_bogs, 
marshy_areasJn_northernJatitudes 

boulder_field  area 

boulder_strewn_beach, 

glacial_moraine 

brushjand  area 

bamboo,  cane 

woods,  brushwood 

butte  area 

cave  area 

cave 

cay 

crevice,  crevasse 

crevasse,  crevice 

dryjake  area 

X 

escarpment  directed Jine 

bluff,  cliff,  escarpment 

abrupt_slope,  abrupt_scarp, 
high_cliff 

esker  line 

esker 

X 

exposed_bedrock  area 

exposed_bedrock 

fan 

geologic_fault  line 

fault 
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JC3IEDM  geographic  or 
facility  category  code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

X 

foreshore  area 

foreshore,  beach,  shoreline,  foreshore 
(precisejho),  coastline 

sand,  sand_beach,  shoreline, 
wet_sand,  gravel_beach 

frozen_precipitation_field  area 

snow_field,  ice_field, 
permanent_snowfield 

glacier,  icefield,  snowfield 

glacier  area 

glacier 

X 

grassjand  area 

grassland,  grass,  scrub,  brush 

tropical_grass 

ground_surface_ 

element  area 

ground_surface_element,  land_area, 
land_region,  barren_ground 

X 

gully  area,  gully  line 

us_gully,  us_gorge  uk_gullies 

perennial_ditch 

jungle  area 

X 

hill 

hummock 

hummocks_and_ridgesJn_swamps, 

hummocks_and_ridgesJn_marshes 

ice_cliff  directed Jine 

ice_cliff 

highjce_cliff,  low_ice_cliff 

ice_peak,  nunatak 

ice_shelf 

X 

island 

land_flooding_ 

periodically  area 

land_subject_to  inundation 

land_subject_to_inundation 

large_isolated_rock,  boulder,  or 
rocky_formation_surrounded_by_water 

mesa  area 

ledge 

mixed_vegetation_land  area 

miscellaneous_vegetation,  scrub,  brush, 

bush 

scatteredjrees 

moraine  area 

moraine 

X 

mountain_pass  line 

mountain_pass 

mountain_pass 

oasis 

X 

packjce  area 

packjce 

pingo 

polarjce  area 

polarjce 

X 

rocky_outcrop  area,  rocky_outcrop 

line 

rock_strata,  rock_formation 

salt_pan  area 

salt_pan 

sand_bar  line 

X 

sand_dune_region  area 

sand_dune,  sand_hills 

crescent_dunes,  lateral_dunes 

sebkha  area 

sebkha 

surface_fissure  line 
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JC3IEDM  geographic  or 
facility  category  code 

00S  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

X 

terrain_depression  area 

depression 

depression 

X 

treed_tract  area 

forest 

mangrove,  nipa 

tundra  area 

tundra 

valley_region  area 

vegetated_saturated_land  area 

volcanic_dyke  line 

volcanic_dike 

volcano 

wadi  area 

wide_wash  or  dry_river_bed, 
narrow_wash  or  dry_stream 

wadi  directed Jine 

waterbody_bank  line 

river_bank,  inland_shoreline 

X 

woody_grass_land  area 

scrub 

Table  A2.  Enumeration  values  for  Feature_Type  attribute,  Terrain  class  OPEN_TRACTS. 


JC3IEDM  geographic  or 
facility  category  code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

X 

aerodrome  area 

airport_area,  us_airfield,  uk_airstrip, 
us_airport,  uk_airport,  airfield,  airstrip, 
landing_place 

airport,  airfield,  landing_ground 

X 

aircraft_parking_ 

facility  area 

us_apron,  us_hardstand,  uk_apron, 
uk_hardstanding 

animal_park  area 

zoo,  safari_park 

athletic_field  area 

us_a th  1  eti c_f i e  1  d ,  u  k_at h  1  eti c_f ie  1  d , 
uk_sports_field,  us_playing_field 

X 

campground  area 

campground,  campsite 

X 

cropjand  area 

cropland 

drove 

flood_basin  area 

golf_course  area 

golf_course 

golf_driving_range 

greenspace 

X 

helicopter_landing_ 

pad  point 

helicopter_landing_pad 
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JC3IEDM  geographic  or 
facility  category  code 

00S  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

hop_field  area 

hops 

X 

man_made_clearing  area 

land_devoid_of_vegetation, 

disturbed_soil 

man_made_clearing  line 

us_cleared_way,  us_cut_line, 
us_firebreak,  uk_cleared_way, 
uk_fi  rebreak 

X 

petroleum_field  area 

prepared_defensive_ 

region  area 

rice_field  area 

rice_field 

rice_paddy 

X 

runway  area 

runway  line 

runway 

runway_stopway  line 

overrun,  stopway 

shoreline_landing_ 

place  area 

shoreline_landing_ 

place  point 

X 

systematic_tree_ 

planting  area 

nursery,  orchard,  plantation 

orchard  or  plantation 

taxiway  line 

training_area 

touchdown_zone 

tree_blowdown  area 

X 

vehiclejot  area 

us_vehicle_storage,  us_parking_area, 
uk_vehicle_storage,  uk_parking_area, 
uk_car_park,  uk_boat_park 

vineyard  area 

vineyards 

vineyard 

Table  A3.  Enumeration  values  for  Feature_Type  attribute,  Terrain  class  FACILITY. 


JC3IEDM  geographic  or 
facility  category  code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

amusement_park  area 

amusement_park 

archeological_site 

assembly_plant_area 

assembly_plant,  works 
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JC3IEDM  geographic  or 
facility  category  code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

us_boardwalk,  uk_wooden_causeway 

botanical_garden 

X 

built_up_region  area 

built_up_area,  settlement 

built_up_area,  town,  village, 

settlement 

built_up_terrain  directed Jine 

camp 

cave_3d  line 

X 

cemetery  area 

us_cemetery,  uk_cemetery,  uk_graveyard 

cemetery 

circular_irrigation_system 

X 

communication_station  area 

courtyard  area 

crib  area 

crib 

culvert  line 

culvert 

dam  area 

dam,  weir 

large_masonry_dam,  diversion_dam 

X 

dam  line 

small_dam 

decontamination_pad 

X 

defensive_position  area 

fort 

disposal_site  area 

us_disposal_site,  us_waste_pile, 
uk_refuse_tip,  uk_slag_heap 

drive_in_theatre  area 

us_drive_in_theater,  uk_drive_in  theatre 

us_drive_in_theater_screen, 
uk_drive_in_theatre_  screen 

electrical_signaljine  line 

telephone_line,  telegraphjine, 
overhead_cable 

exhibition_grounds 

extraction_mine  area 

mine_dump,  strip_mine,  tailings_pile 

fairground  area 

us_fairgrounds,  uk_fairgrounds 

feedjot,  stockyard,  holding_pen 

ferry_crossing  line 

ferry_crossing 

ferry 

filtration_beds,  aeration_beds 

firing_range,  gunnery_range 

fish_hatchery  area 

fish_hatchery,  fish_farm,  marine_farm 

fishing_pier,  promenade_pier 

heating_plant 

fortification  area 

grain_elevator  line 
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JC3IEDM  geographic  or 
facility  category  code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

grain_storage_structure  line 

X 

heliport  area 

heliport 

heliport 

historical_built_up_area 

historical_battlefield 

hydrographicjock  area 

hydrographicjock  line 

i rrigation_d itch  area 

landing_stairs 

lookout 

land_fish_hatchery  area 

levee  line 

dyke_crown 

smalljevee 

livestock_pen  area 

marine_wreck  area 

wreck 

X 

m  i  1  ita  ry_f  a  c  i  1  ity  area 

military_base 

X 

missile_site  area 

missile_site 

mobile_home_park  area 

us_mobile_home,  us_mobile 
_home_park,  uk_caravan, 
uk_caravan_park,  uk_mobile_home, 
uk_mobile_home_park 

native_settlement  area 

native_settlement 

native_settlement 

X 

nuclear_weapons_ 

facility  point 

offshore_loading_ 

facility  area 

us_offshore_loading_facility, 

uk_single_point_mooring 

oil_  facilities,  gas_facilities 

oil_field,  gas_field 

park  area 

park 

parking_garage  point 

particle_accelerator  area 

particle_accelerator 

X 

petroleum_facility  area 

X 

pipeline  line 

pipeline,  pipe 

pipeline, 

elevated_conduit_of_any_type 

plant_nursery  area 

X 

power_plant  point 

us_power_plant,  uk_power_station 

power_substation  area 

substation,  transformer_yard 

picnic_site 

pit 

port_facility 
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JC3IEDM  geographic  or 
facility  category  code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

X 

power_transmission  line 

power_transmission_line 

power_lines,  telephonejines, 
telegraph_lines 

prepared_defensive_ 

position_site  area 

prepared_raft_bridge_site, 

prepared_float_bridge_site 

X 

processing_facility  area 

processing_plant,  treatment_plant, 
waste_processi  ng_faci  1  ity 

productionjnstallation 

public_square  area 

plaza_square,  city_square 

X 

pumping_station  point 

pumping_station 

X 

quarry  area  ,  quarry  line 

quarry,  mine,  quarry_shear_wall, 
mine_shear_wall 

quarry,  open_pit_mine 

race_track  area 

us_race_track,  uk_race_track, 
uk_race_course 

race_track 

radar_station  point 

railroad_turntable  area 

us_railroad_turntable, 

uk_railway_turntable 

turntable 

X 

railroad_yard  area 

us_ra  i  1  road_yard ,  us_ma  rsha  1 1  i  ng_yard , 
uk_railway_yard,  uk  marshalling  yard. 

railhead 

railroad_yard,  railroad_siding 

roadside_rest_stop  point 

us_vehicle_stopping,  us_vehicle_area, 
us_vehicle_rest_area, 
uk_vehicle_stopping_area, 
uk_vehicle_rest_area,  uk_vehicle_lay_by 

rubble  area 

ramp 

ramp_maritime 

X 

ruins  area 

ruins 

ruined_or_destroyed_area 

scrapyard  area 

wrecking  yard,  scrap_yard 

seaplane_base  area 

seaplane_base 

seaplane_base 

settlement  area 

shore_protection_ 

structure  area 

sidewalk  line 

X 

storage_depot  area 

ski_track 

X 

slipway,  patent_slip 

small_craft_facility 

taxiway  area 

taxiway 
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JC3IEDM  geographic  or 
facility  category  code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

test_area 

timber_yard 

treeline  line 

X 

tunnel_shelter  area 

water_treatment_bed  area 

X 

weapon_fighting_ 

position  point 

weapon_full_ 

defilade_position  point 

weapon_hull_defilade_position 

point 

weapon_turret_ 

defilade_position  point 

weapons_range  area 

X 

wharf  line 

us_pier,  us_wharf,  us_quay,  uk_pier, 
uk_wharf,  uk_quay,  ukjetty 

wharf,  pier,  dock 

Table  A4.  Enumeration  values  for  Feature_Type  attribute,  Terrain  class  SITES. 


JC3IEDM  geographic  or 
facility  category  code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

X 

aircraft_hangar  point 

bastion,  rampart,  fortification 

blastfurnace  point 

blastfurnace 

X 

building  area 

building  point 

building,  cabin, 

building_superstructure_addition,  hut, 
cliff_dwelling,  arcade, 
amusement_park_attraction,  shed, 
us_steeple,  uk_steeple,  uk_spire, 
station_miscellaneous 

buildings_in_general, 
structures_similar_to_buildings, 
school,  church, 

non_christian_house_of_worship, 
mosque,  pagoda,  greenhouse, 
landmark_building,  railroad_station 

X 

bunker  point 

fortification 

catalytic_cracker  point 

catalytic_cracker 

X 

communication_station  point 

communication_building 

X 

control_tower  point 

controLtower 

X 

dry_dock  point 

us_drydock,  uk_dry_dock 

drydock 
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JC3IEDM  geographic  or 
facility  category  code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

X 

early_warning_radar_site  point 

early_wa  rn  i  ng_rada  r_site 

fortification_wall  point 

grain_elevator  point 

grain_elevator 

grain_storage_structure  point 

grain_bin,  grain_silo 

grandstand  area 

grandstand 

grandstand  point 

hardened_aircraft_ 

shelter  point 

revetment  (airfield/equipment/facilities ) 

historic_site,  historic_point_of_interest 

historical_site 

X 

individual_fighting_ 

position  point 

X 

infantry_trench  line 

X 

i  rrigation_d  itch  directedjine 

ditch,  trench 

X 

jetty  line 

groin,  breakwater,  breakwater_or_groyne, 
usjetty,  uk_training_wall 

jetty 

X 

lighthouse  point 

lighthouse 

lighthouse_or_light 

main_telecom_ 

exchange  point 

marine_mole  line 

mole 

marine_signal_station  point 

maritime_station,  maritime_signal_station 

X 

nuclear_reactor  point 

nuclear_reactor 

protection_shed  line 

snow_shed,  rock_shed 

railroad_snowshed 

rampart  line 

rig  point 

rig,  superstructure 

rubble  point 

X 

ruins  point 

ruins 

seawall  line 

seawall 

large_seawall, 

narrow_seawall_or_revetment, 

large_revetment 

christian_shrine, 

non_christian_shrine,  moslem_shrine 

shore_protection_ 

structure  line 

revetment_shore_protection,  rip_rap 

small_breakwater,  large_breakwater 

shoreline_construction,  mooring_facility, 
warping_facility 

sports_arena  area 

us_stadium,  us_amphitheater, 
uk_stadium,  uk_ampitheatre 

sports_arena  point 

step_flight  line 

flight_of_steps 
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JC3IEDM  geographic  or 
facility  category  code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

storage_bunker  point 

storage_bunker,  storage_mound 

storage_tank  point 

tank 

tank 

swimming_pool  area 

swimming_pool  point 

swimming_pool 

swimming_pool 

telecom_switching_ 

station  point 

X 

underground_bunker  point 

underground_bunker 

X 

wall  line 

prominent_wall 

warehouse  point 

depot_storage 

X 

water_tower  point 

water_tower,  tower_general 

X 

windmill  point 

windmill 

windmill_or_windpump 

Table  A5.  Enumeration  values  for  Feature_Type  attribute,  Terrain  class  WATERBODY. 


JC3IEDM  geographic  or 
facility  category  code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

X 

anchor_berth 

X 

anchorage 

anchorage_complex_feature 

aqueduct  area 

aqueduct 

aqueduct  directed Jine 

aqueduct_tunnel 

backshore_precise_iho 

X 

basin 

X 

berth 

boat_turning_basin 

bottom_feature 

breaker_region  area 

breakers 

X 

canal  area 

canal 

abandoned_canal, 

abandoned_canal_containing_water 

X 

canal  directed  Jine 

canal_route 

navigable_canal_in_ope  ration 

channel 

common_open_water 

eddies 
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JC3IEDM  geographic  or 
facility  category  code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

flooded_area 

flume 

flume 

X 

ford  line 

ford 

ford 

inland_water 

lagoon  area 

lagoon,  reef_pool 

X 

lake  area 

lake,  pond 

perinnealJake_or_pond, 

dry_or_cyclical_lake_or_pond, 

fish_ponds, 

intermittent_lake_or_pond 

lock_basin 

marine_foul_ground  area 

us_foul_ground,  uk_foul 

marine_region  area 

maritime_area,  depth_area 

marine_region  line 

marine_region  point 

marine_route  area 

route_maritime 

marine_route  line 

deep_water_route 

marine_route  point 

miscellaneous_surface_drainage_feature 

intermittent_ditch 

miscellaneous_underwater_feature 

d  isa  ppea  ri  ng_strea  m 

moat  area 

moat 

nearshore_precise_iho 

overfalls,  tide_rips 

rapid  line 

rapids 

small_rapids,  large_rapids 

reef  area,  reef  line 

reef 

X 

reservoir  area 

reservoir 

reservoir_with_natural_shoreline 

X 

river  area 

river_navigation_route 

wide_perennia  l_strea  m , 
narrow_perennial_stream, 
braided_stream,  unclassified_stream, 
i  nte  r  m  itte  nt_strea  m 

X 

river  directed Jine 

river,  stream 

safety_fairway  area  , 
safety_fairway  line 

safety_fairway 

salt_evaporator  area 

salt_evaporator 

salt_evaporator 

seaplanejanding,  seaplane_takeoff_area 

seaplane_anchorage 

settling_pond  area 

settling_basin,  sludge_pond 

spillway 

snag  area 

us_snags,  us_stumps,  uk_snags, 
us_submerged_stumps 
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JC3IEDM  geographic  or 
facility  category  code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

swept_region  area,  swept_region 

line 

swept_area 

tideway 

us_current_flow,  uk_current_flow, 
uk_tidal_stream_direction 

us_harbor,  uk_harbour 

us_harbor_complex,  uk_harbour_complex 

underwater_hazard  area 

underwater_hazard  line 

waterbody_floor  area 

X 

water_except_inland  area 

water_except_inland 

water_turbulence 

waterfall  line 

waterfall 

large_falls,  small_falls 

watering_hole  point 

Table  A6.  Enumeration  values  for  Feature_Type  attribute,  Terrain  class  ROAD. 


JC3IEDM  geographic  or 
facility  category  code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

breach  line 

X 

bridge  line 

bridge,  overpass,  viaduct 

highway_bridge_or_viaduct, 

highway_drawbridge, 

railroad_bridge_or_viaduct, 

railroad_drawbridge 

cart_track  line 

cart_track 

causeway  line 

causeway 

small_levee_carrying_railroad, 

small_levee_carrying_road 

constriction,  expansion 

driveway  line 

engineer_bridge  line 

overpass  line 

overpass_or_underpass 

point_of_changeJn_the_gage_or_num- 

ber_of_tracks 

point_of_change_in_number_of_lanes_ 

of_extra_width_road 
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JC3IEDM  geographic  or 
facility  category  code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

X 

railroad  line 

us_railroad,  uk_railway, 
us_railroad_switch,  uk_railway_points 

single_track_railroad_in_operation, 
single_track_railroad_nonope  rating, 
double  _or_multiple_track 
_ra  i  1  road  _i  n_operation , 
double_or_multiple_track- 
_railroad_nonoperating,  rail- 
road_in_street_or_wharf 

railroad_sidetrack  line 

us_railroad_siding,  us_railroad_spur, 
uk_railway_siding,  uk_railway_spur 

X 

road  line 

roadjane  directedjine 

road,  us_sharp_curve,  uk_sharp_bend 

hard_surface_heavy_duty_road, 

hard_surface_medium_duty_road, 

improved_light_duty_road, 

unimproved_dirt_road, 

ha  rd_su  rface_a  1  l_weather_road_two_ 

or_more_lanes_wide, 

hard_surface_all_weather_road_one_ 

lane_wide,_loose_or_light_surface_all 

_weather_road_two_or_more_lanes_ 

wide, 

loose_or_light_surface_all_weather_ 

road_one_lane_wide, 

1  oose_s  u  rface_fa  i  r_or_d  ry_weat  h  e  r_ 
road,  dual_or_super_highway, 
main_road,  secondary_road, 
other_road,  road_under_construction, 
streets_in_developed_areas, 
street_ending_at_barrier_or_embank 
ment,  dam_carrying_road 

X 

roadjnterchange  line 

us_interchange,  ukjnterchange, 
uk_complexJunction 

interchange,  cloverleaf,  traffic_circle, 
grade_crossing 

trail  line 

trail,  track 

shoulder 

steep_grade 

steep_gradients_on_roads 

X 

tunnel  3d  line 

tunnel 

road_tunnel,  railroad_tunnel 

underground_railroad  3d  line 

us_subway,  uk_underground_railway, 
uk_metro 

weapon_fighting_position_access_ro 

ute  line 
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Table  A7.  Attributes  of  Terrain  subclass  TRAFFICABILITY_SURFACE.* 


Attribute  Name  (from 

EDCSt) 

Attribute  Definition 

Cardinality 

Data  Type 

Enumeration  Values  or  Units* 

Area 

The  absolute  area  within  the  area  of  an 

object. 

1 

float 

m2 

Name 

The  textual  identifier  or  code  used  for  an 

object;  the  name. 

0 

string 

none  (name  may  be  "missing") 

Frozen_Soil_Layer_ 

Bottom_Depth 

The  depth  from  the  terrain  to  the  base  of  a 
layer  of  frozen  soil. 

1 

float 

meters 

Frozen_Soil_Layer_ 

Top_Depth 

The  depth  from  the  terrain  to  the  top  of  a 
layer  of  frozen  soil. 

1 

float 

meters 

Frozen_Water_Type 

The  type  of  frozen  water  present. 

1 

integer 

0001  ice 

0002  melting_snow_or_ice 

0003  mixed_snow_and_ice 

0004  none_present 

0005  slush 

0006  snow 

0007  snow_over_ice 

Maximun_Standing 
_Water_  Depth 

The  maximum  depth  of  non- 
flowing/standing  water  within  the  region 
delineated  by  an  object. 

0 

float 

meters 

Snow_Density 

The  density  of  accumulated  snow  on  an 
object. 

0 

float 

(specific  gravity)  or  g/cc 

Snow_Depth 

The  depth  of  snow  and/or  ice  on  the 

terrain. 

0 

float 

meters 

Snow_Only_Depth 

The  depth  of  the  snow,  which  may  be  over 
terrain,  ice,  or  floating  ice. 

0 

float 

meters 

Soil_Cone_lndex_QB5_ 

Measurement  _Depth 

Soil  cone  index  at  measurement  depth: 
[0,15],  [15,30]  where  measurement 
depths  (cm). 

1 

integer 

kPa 

Soil_Density_Dry 

The  average  density  of  the  soil  between 

the  surface  and  the  bedrock  after  it  has 

been  dried  to  a  constant  mass  at  105°C. 

0 

float 

(specific  gravity)  or  g/cc 

*  Subclass:  TRAFFICABILITY_SURFACE  -  a  set  of  attributes  associated  with  the  terrain  surface  from  which  mobility 
calculations  can  be  made,  specifically  supports  the  use  of  the  STNDMob  API,  but  will  support  other  models  also. 

t  Some  precipitation  and  state-of-the-ground  attributes  will  also  be  found  in  the  Weather  category;  within  the  Terrain 
category,  these  values  are  related  to  specific  instance  of  the  class,  within  the  Weather  category  they  are  related  to  a 
regional  area.  In  most  cases  the  values  will  be  the  same,  however  not  always,  e.g.  the  snow  cover  depth  based  on  the 
Weather  category  may  be  10  cm,  for  a  region,  for  a  specific  road  within  that  region  the  snow  depth  could  be  zero 
because  it  had  been  plowed.  Mobility  analysis  would  be  based  on  the  Terrain  category  attributes,  which  must  be 
dynamically  updated  based  on  the  Weather  category  information,  reconnaissance  reports  or  other  services. 

t  The  OOS  EDM  does  not  specify  units  of  measure  for  these  attributes.  Each  attribute  needs  a  subclass  "UnitsOfMeasure" 
values  stated  are  recommended. 

§  QB  -  “qualified  by’’ 
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Attribute  Name  (from 

EDCS+) 

Attribute  Definition 

Cardinality 

Data  Type 

Enumeration  Values  or  Units* 

Soil_Depth 

The  general  depth  of  soil,  or 
unconsolidated  material,  from  terrain  to 

bedrock. 

0 

float 

meters 

Soil_Type 

The  Unified  Soil  Classification  System 
(USCS)  Soil_Type. 

0 

integer 

0007  ch 

0008  cl 

0009  evaporites 

0010  gc 

0011 gm 

0012  gp 

0013  gw 

0014  mh 

0015  ml 

0016  ml_and_cl 

0018  oh 

0019  ol 

0020  pt 

0021  sc 

0022  sm 

0023  sm_and_sc 

0024  sp 

0025  sw 

unknown 

Soil_Water_Volume 

The  water  lost  from  the  soil  upon  drying  to 
constant  mass  at  105°C,  expressed  as  the 
fractional  volume  of  water  per  unit  bulk 

volume  of  wet  soil. 

0 

float 

none 

Soil_Wetness 

The  categorical  (coded)  soil  water  content, 
whether  liquid  or  solid. 

0 

integer 

0002  average 

0003  dry 

0005  frozen_or_permafrost 

0006  moist 

0001  perenially_dry 

0008  saturated 

0009  waterlogged 

0010  wet 

Surface_Slippery 

Indication  that  a  surface  is  slippery. 
Examples:  wet  grass,  and  wet  clay  soil. 

1 

boolean 

none 

Terrain 

_Roughness_Root_ 

Mean_Square 

The  roughness  of  terrain  based  on 
elevation  variations,  calculated  using  the 
root-mean-square  (RMS)  value  of  the 
detrended  terrain  elevation  measured  at  a 

spatial  frequency  of  approximately  0.3  m. 

0 

float 

meters 

Terrain_Trafficability_Fine 

The  categorized  character  of  the  terrain  as 
it  affects  the  movement  of  ground  forces 
(e.g.,  military  units,  vehicles,  or  infantry)  in 

terms  of  a  fine  resolution  estimate  of 

trafficability. 

0 

integer 

0650  ID_683  .... 
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Attribute  Name  (from 

EDCS+) 

Attribute  Definition 

Cardinality 

Data  Type 

Enumeration  Values  or  Units* 

Terra  i  n_T  raff  ica  bi  1  ity_Me- 

dium 

The  categorized  character  of  the  terrain  as 
it  affects  the  movement  of  ground  forces 
(e.g.,  military  units,  vehicles,  or  infantry)  in 

terms  of  a  medium  resolution  estimate  of 

trafficability. 

0 

integer 

0001  ID_001 

Terrain 

_Trafficabilty_Coarse 

The  categorized  character  of  the  terrain  as 
it  affects  the  movement  of  ground  forces 
(e.g.,  military  units,  vehicles,  or  infantry)  in 

terms  of  a  coarse  resolution  estimate  of 

trafficability. 

0 

integer 

0005  Default 

Terrain_Transportation_ 

Route_Surface_Type 

The  physical  surface  composition  of  a 
road,  runway  or  other  surface  intended  to 
support  the  movement  of  vehicles. 

0 

integer 

0001  asphalt 

0002  bituminous 

0003  brick 

0004  clay 

0005  composite_non_permanent  hard 

0006  composite_permanent 

0007  concrete 

0008  coral 

0009  corduroy 

0010  graded_soil 

0011  gravel 

0012  hard 

0013  ice 

0014  laterite 

0015  loose 

0016  macadam 

0017  membrane 

0018  mix_in_place 

0019  mixed_concrete_asphalt 

0020  natural 

0021  permanent 

0022  sand 

0023  snow 

0024  sod 

0025  steeLgrating 

0026  steeLplanking 

0027  temporary 

0028  ungraded 

0029  unpaved 

0030  wood 
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Table  A8.  Attributes  of  Terrain  subclass  TRAFFICABILITYVEGETATION.* 


Attribute  Name  (from  EDCS) 

Attribute  Definition 

Cardinality 

Data 

Type 

Enumeration  Values  or  Units+ 

Brush_Density 

The  fraction  of  ground  covered  by 
undergrowth  (e.g.,  scrub,  brush,  or 
bush)  within  the  area  of  an  object. 

1 

float 

none 

Maximum_Visibility_Range 

The  maximum  range  of  visibility  into 
an  object,  e.g.,  a  forest. 

1 

integer 

meters 

Mean_Stem_Diameter 

The  mean  vegetation  stem  diameter 
within  the  area  of  an  object,  measured 
at  a  height  of  1.4  m  above  the  terrain. 

0 

float 

meters 

Mean_Stem_Spacing_ 

QB_Stem_Diameter 

Mean_Stem_Spacing  of  all  stems  of 

stem  diameter: 

(0.0,  opent), 

(2.5,  open), 

(6.0,  open), 

(10.0,  open), 

(14.0,  open), 

(18.0,  open), 

(22.0,  open), 

(25.0,  open) 

0 

float 

meters 

Vegetation_Type 

The  type  of  vegetation. 

0 

integer 

0001  agri_scattered_forests 

0002  agri_scattered_trees 

0003  almond 

0004  apple 

0005  artemisia 

0006  ash 

0007  bamboo 

0008  beech 

0009  birch 

0010  black_spruce 

0011  bog 

0012  brushland_medium_to_dense 

0013  brushland_open_to_medium 

0014  carob 

0015  casuarina 

0016  chestnut 

0017  citrus 

0018  conifer 

0019  cork_oak 

0020  corn 

0021  cranberry 

*  Subclass:  TRAFFICABILITY_VEGETATION  -  a  generic  list  of  attributes  associated  with  vegetation  from  which  mobility 
calculations  can  be  made,  specifically  supports  the  use  of  the  STNDMob  API,  but  will  support  other  models  also, 
t  The  OOS  EDM  does  not  specify  units  of  measure  for  these  attributes.  Each  attribute  needs  a  subclass  "UnitsOfMeasure" 
values  stated  are  recommended. 

t  The  term  “open”  implies  and  greater. 
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Attribute  Name  (from  EDCS) 

Attribute  Definition 

Cardinality 

Data 

Type 

Enumeration  Values  or  Units+ 

0022  cypress 

0023  deciduous_unspecified 

0024  dry_crops 

0025  elm 

0026  eucalyptus 

0027  evergreen_unspecified 

0028  filao 

0029  fir 

0030  forest_clearing 

0031  garden 

0032  grass 

0033  grassland 

0034  grasland_scattered_trees 

0035  grove 

0036  hardwood 

0037  hazel 

0038  heath 

0039  ilex 

0040  joshuajxee 

0041  kelp 

0042  larch 

0043  mangrove 

0044  maple 

0045  marsh 

0046  mixed_crops 

0047  mixed_deciduous 

0048  mixed_trees 

0049  moss 

0050  nipa_palm 

0051  non_treed 

0052  oak 

0053  olive 

0054  palm 

0055  peach 

0056  peat 

0057  pine 

0063  poplar 

0064  reed 

0065  rhanterium 

0066  rice_paddies 

0067  sargasso 

0068  sea_grass 

0069  sea_weed 

0070  swamp 

0071  swamp_deciduous 

0072  swamp_evergreen 
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Attribute  Name  (from  EDCS) 

Attribute  Definition 

Cardinality 

Data 

Type 

Enumeration  Values  or  Units* 

0073  swamp_mangrove 

0074  swamp_mixed 

0075  tropical_grass 

0081  vineyards_hops_genseng 

0082  walnut 

0083  wet_crops 

0084  wheat 

0085  with_trees 

0086  without_trees 

3006  undesignated 

Table  A9.  Attributes  of  Terrain  subclass  TRAFFICABILITY_WETGAPS.* 


Attribute  Name  (from  EDCS*) 

Attribute  Definition 

Cardinality 

Data 

Type 

Enumeration  Values  or  Units* 

Height_Above_Surface_Level 

The  height  measured  vertically  from 

the  terrain  or  WATERBODY  surface.  For 

physical  objects,  measured  from  the 
lowest  point  of  the  object  base 
(downhill  side/downstream  side)  to 
the  highest  point  of  the  object. 

1 

float 

meters 

Hydrologic_Permanence 

The  persistence,  overtime,  of  a 
hydrologic  object. 

1 

integer 

0001  dry 

3003  missing  (unknown) 

0002  non_perennial 

0004  perennial_or_permanent 

lce_Layer_Thickness 

The  thickness  of  the  layer  of  ice  that 
covers  a  WATERBODY. 

1 

float 

meters 

Left_Above_Bank_Slope 

The  slope  (rise/run)  of  the  left  bank 
(facing  downstream)  of  a  watercourse 

above  the  mean  water  level. 

1 

float 

none 

*  Subclass:  TRAFFICABILITY_WETGAPS— a  generic  list  of  attributes  associated  with  water  features  from  which  ground 
vehicle  mobility  calculations  can  be  made,  specifically  supports  the  use  of  STNDMob  API,  but  will  support  other  models 
also. 

t  Some  precipitation  and  state-of-the-ground  attributes  will  also  be  found  in  the  Weather  category;  within  the  Terrain 
Category,  these  values  are  related  to  specific  instance  of  the  class,  within  the  Weather  category  they  are  related  to  a 
regional  area.  In  most  cases  the  values  will  be  the  same,  however  not  always,  e.g.  the  Snow_Depth  based  on  the 
Weather  category  may  be  10  cm,  for  a  region,  for  a  specific  road  within  that  region  the  Snow_Depth  could  be  zero 
because  it  had  been  plowed.  Mobility  Analysis  would  be  based  on  the  Terrain  category  attribution,  which  must  be 
dynamically  updated  based  on  the  Weather  category  information,  reconnaissance  reports  or  other  services. 

t  The  OOS  EDM  does  not  specify  units  of  measure  for  these  attributes.  Each  attribute  needs  a  subclass  "UnitsOfMeasure" 
values  stated  are  recommended. 
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Attribute  Name  (from  EDCS*) 

Attribute  Definition 

Cardinality 

Data 

Type 

Enumeration  Values  or  Units* 

Left_Bank_Height 

The  height  of  the  left  bank  (facing 
downstream)  of  a  watercourse, 

measured  from  mean  water  level  to 

the  first  break  in  slope  above  the 

mean  water  level. 

1 

float 

meters 

Left_Bank_Soil_Cone_ 

Index 

The  soil  cone  index  of  the  left 

WATERBODY  bank. 

1 

float 

kPa 

Maximum_Water_Depth 

The  maximum  WATER_DEPTFI  within 
the  region  delineated  by  an  object. 

1 

float 

meters 

Mean_Water_Depth 

The  mean  depth  of  the  water  from  a 
specified  surface  datum  to  a 
WATERBODY  floor,  as  a  positive 

number. 

1 

float 

meters 

Mean_Water_Speed 

The  mean  rate  of  horizontal  motion  of 
a  water  parcel,  estimated  within  the 
delineation  of  a  WATERBODY, 
exclusive  of  high  water  current  due  to 

runoff  or  low  water  current  due  to 

drought 

1 

float 

meters  per  second 

Right_Above_Bank_ 

Slope 

The  slope  (rise/run)  of  the  right  bank 
(facing  downstream)  of  a  watercourse 

above  the  mean  water  level. 

1 

float 

none 

Right_Bank_Height 

The  height  of  the  right  bank  (facing 
downstream)  of  a  watercourse, 

measured  from  mean  water  level  to 

the  first  break  in  slope  above  the 

mean  water  level. 

1 

float 

meters 

Right_Bank_Soil_Cone_ 

Index 

The  soil  cone  index  of  the  right 

WATERBODY  bank. 

1 

float 

kPa 

Waterbody_Floor_Clutter_De 

nsity 

The  spatial  density  of  objects  on  a 
WATERBODY  floor,  within  a  delineated 
region,  which  appear  to  acoustic 
sensors  to  be,  but  are  not,  explosive 

mines. 

1 

float 

Waterbody_Floor_Material_T 

ype 

The  predominant  type  of  material 
composition  of  the  WATERBODY  floor. 

1 

0001  bedrock  sand_and_gravel 

0002  clay_and_silt 

0003  coral 

0004  gravel_and_cobble 

0005  mixed_qualities 

0006  paved 

0007  peat 

0008  rocks_and_boulders 

0009  rocky_outcrop 

0010  sand 

0011  sand_and_gravel 

0012  sand_and_mud 

0013  silty_sands 

0014  slash 

Waterbody_Surface_lce_Fra 

ction 

The  fraction  of  a  WATERBODY  surface 

covered  by  ice. 

1 

float 
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Attribute  Name  (from  EDCS*) 

Attribute  Definition 

Cardinality 

Data 

Type 

Enumeration  Values  or  Units* 

Frozen_Water_Type 

The  type  of  frozen  water  present. 

1 

integer 

0001  ice 

0002  melting_snow_or_ice 

0003  mixed_snow_and_ice 

0004  none_present 

0005  slush 

0006  snow 

0007  snow_over_ice 

Snow_Density 

The  density  of  accumulated  snow  on 
an  object. 

0 

float 

(specific  gravity)  or  g/cc 

Snow_Depth 

The  depth  of  snow  and/or  ice  on  the 

terrain. 

0 

float 

meters 

Snow_Only_Depth 

The  depth  of  the  snow,  which  may  be 
over  terrain,  ice,  or  floating  ice. 

0 

float 

meters 

Table  A10.  Attributes  of  Terrain  subclass  TRAFFICABILITY_DRYGAPS.* 


Attribute  Name  (from 

EDCS) 

Attribute  Definition 

Cardinality 

Data 

Type 

Enumeration  Values  or  Units* 

Depth_Below_Surface_ 

Level 

The  distance  measured  from  the  highest 
point  at  surface  level  to  the  lowest  point 
of  an  object  below  the  surface,  as  a 
positive  number. 

1 

float 

meters 

Surface_Slope 

The  maximum  slope  (rise/run)  of  the 
surface  of  an  object. 

1 

float 

none 

Height_Above_Surface_ 

Level 

The  height  measured  vertically  from  the 

terrain  or  WATERBODYsurface.  For 
physical  objects,  measured  from  the 
lowest  point  of  the  object  base  (downhill 
side/downstream  side)  to  the  highest 
point  of  the  object. 

1 

float 

meters 

Left_Above_Bank_Slope 

The  slope  (rise/run)  of  the  left  bank 
(facing  downstream)  of  a  watercourse 

above  the  mean  water  level. 

1 

float 

none 

Left_Bank_Height 

The  height  of  the  left  bank  (facing 
downstream)  of  a  watercourse, 

measured  from  mean  water  level  to  the 

first  break  in  slope  above  the  mean 

water  level. 

1 

float 

meters 

*  Subclass:  TRAFFICABILITY_DRYGAPS— a  generic  list  of  attributes  associated  with  gap  crossing  (dry  ditches,  trenches 
craters)  from  which  ground  mobility  calculations  can  be  made,  specifically  supports  the  use  of  the  STNDMob  API,  but  will 
support  other  models  also. 

t  The  OOS  EDM  does  not  specify  units  of  measure  for  these  attributes.  Each  attribute  needs  a  subclass  "UnitsOfMeasure" 
values  stated  are  recommended. 
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Attribute  Name  (from 

EDCS) 

Attribute  Definition 

Cardinality 

Data 

Type 

Enumeration  Values  or  Units+ 

Left_Bank_Soil_Cone_ 

Index 

The  soil  cone  index  of  the  left 

WATERBODY  bank. 

1 

float 

kPa 

Right_Above_Bank_Slope 

The  slope  (rise/run)  of  the  right  bank 
(facing  downstream)  of  a  watercourse 

above  the  mean  water  level. 

1 

float 

none 

Right_Bank_Height 

The  height  of  the  right  bank  (facing 
downstream)  of  a  watercourse, 

measured  from  mean  water  level  to  the 

first  break  in  slope  above  the  mean 

water  level. 

1 

float 

meters 

Right_Bank_Soil_Cone_ 

Index 

The  soil  cone  index  of  the  right 

WATERBODY  bank. 

1 

float 

kPa 

Table  All.  Attributes  of  Terrain  subclass  TRAFFICABILITY_ROAD.* 


Attribute  Name  (from 

EDCS) 

Attribute  Definition 

Cardinality 

Data 

Type 

Enumeration  Values  or  Unitst 

Bed_Height 

The  height  of  the  bed  of  a  terrain 
transportation  route  above  the 
surrounding  terrain. 

0 

float 

meters 

Existence_Status 

The  status  or  existence  condition  of  an 

object. 

0 

integer 

0001  abandoned 

0012  destroyed 

0043  operational 

0063  under_construction 

Median_Width 

The  width  of  the  divider  between 

multiple  road  lanes,  or  railroad  tracks. 

0 

float 

meters 

Multipass_Surface_ 

Degradation 

The  qualitative  degree  to  which  terrain 
or  a  terrain  transportation  route  has 
been  degraded  by  the  passage  of 

vehicles. 

0 

integer 

0001  heavy 

0002  moderate 

0003  none_present 

Path_Count 

The  number  of  independent,  parallel 
paths  within  a  terrain  transportation 
route  (e.g.,  tracks  or  lanes),  including 

both  directions. 

1 

integer 

*  Subclass:  TRAFFICABILITY_ROAD— a  list  of  attributes  associated  with  M-COP  road  features,  from  which  mobility 
calculations  can  be  made,  specifically  supports  the  use  of  the  STNDMob  API,  but  will  support  other  models  also,  must  be 
used  in  conjunction  with  the  TRAFFICABILITY_SURFACE  subclass. 

t  The  OOS  EDM  does  not  specify  units  of  measure  for  these  attributes.  Each  attribute  needs  a  subclass  "UnitsOfMeasure" 
values  stated  are  recommended. 
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Attribute  Name  (from 

EDCS) 

Attribute  Definition 

Cardinality 

Data 

Type 

Enumeration  Values  or  Unitst 

Road_l_ighting_Present 

Indication  that  a  road  is  illuminated  by 
street  lights. 

0 

boolea 

n 

Road_Minimum_Width 

The  minimum  width  of  a  road  traveled 

way,  determined  by  the  sum  of  the 
widths  of  includedroad  lanes,  excluding 
adjacent  hard  paved  shoulders, 
sidewalks,  and  other  pathways. 

1 

float 

meters 

Sharp_Curve_Radius 

The  radius  of  curvature  of  a  sharpe 
curve  in  a  land  transportation  route. 

1 

float 

meters 

Superelevation 

The  lateral  slope  (rise/run)  of  a  terrain 
transportation  route. 

1 

float 

Terrain_Route_Type 

The  type  of  a  terrain  transportation 

route. 

1 

integer 

0001  primary_road 

0002  secondary_road 

0003  superhighway 

0004  trail 

Terrain_Route_Usable_ 

Weather_Type 

The  type  of  weather  conditions  under 
which  a  terrain  transportation  route  is 

usable. 

1 

integer 

0001  all 

0003  fair_and_dry_only 

3002  missing 

0004  winter_only 

Transportation_Use 

The  type  of  primary  user,  function,  or 
authority  of  a  transportation  system. 

1 

integer 

0011  caravan_route 

0025  road 

0027  road_and_railroad 

0034  street 

0035  through_routes 

Usage 

The  primary  user,  function,  or  controlling 
authority,  of  an  object. 

1 

integer 

0067  international 

0068  interstate 

0088  national 

0093  non_military 

0105  primary 

0107  private 

0130  secondary 

0134  state 

Vehicle_Traffic_Flow 

The  type  of  flow-pattern  of  vehicle  traffic. 

1 

integer 

0002  one_way 

0004  two_way 

Vehicular_Speed_Limit 

The  maximum  speed  legally  permitted 
on  a  given  stretch  of  a  terrain 
transportation  route. 

1 

integer 

kph 

Width 

The  length  of  the  shorter  of  two 
orthogonal  linear  axes  of  an  object, 
measured  in  the  horizontal  plane.  For  a 
square  object,  measure  either  axis.  For  a 
round  object,  width  is  equal  to  length. 

For  a  bridge,  the  width  is  the 
measurement  perpendicular  to  the  axis 
between  the  bridge  piers. 

1 

float 

meters 
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Table  A12.  Attributes  of  Terrain  subclass  TRAFFICABILITY_BRIDGE_TUNNEL.* 


Attribute  Name  (from  EDCS) 

Attribute  Definition 

Cardinality 

Data 

Type 

Enumeration  Values  or  Unitst 

Blockage_Present 

Indication  that  a  passageway  is 

blocked  to  the  movement  of 
vehicles  and/or  personnel. 

1 

boolean 

Bridge_Design 

The  structural  design 
characteristics  of  a  bridge  or 
bridge  span. 

1 

integer 

0001  arch 

0002  bailey 

0003  cantilever 

0004  deck 

0005  floating 

0008  medium_girder 

0009  mltry_armour_veh_launched 

0010  mltry_heavy_assault 

0011  mltry_m4t6 

0012  mltry_pmp 

0013  mltry_tactical 

0014  mltry_tmm 

0015  mobile_assault 

0017  ribbon 

0018  slab 

0020  stringer_beam 

0021  suspension 

0022  transporter_ferry 

0023  truss 

0025  pontoon 

3002  missing 

3006  undesignated 

Bridge_Level_Count 

The  number  of  levels  of  a 

bridge  which  carry  vehicle 
and/or  personnel  traffic. 

1 

integer 

Bridge_Span_Count 

The  number  of  spans  in  a 
bridge  or  aqueduct. 

1 

integer 

Completion_Percentage 

The  extent  of  completion  for  an 
object  in  terms  of  fractional 

ascension  from  start  of 

construction  to  completion  of 

construction. 

1 

float 

Forcejdentifier 

A  textual  identify  of  a  military  or 

civilian  force. 

0 

String 

*  Subclass:  TRAFFICABILITY_BRIDGE_TUNNEL— a  list  of  attributes  associated  with  M-COP  Bridge  and  tunnel  features,  from 
which  mobility  calculations  can  be  made,  specifically  supports  the  use  of  the  STNDMob  API,  but  will  support  other 
models  also,  must  be  used  in  conjunction  with  the  TRAFFICABILITY_ROAD  subclass. 

t  The  OOS  EDM  does  not  specify  units  of  measure  for  these  attributes.  Each  attribute  needs  a  subclass  "UnitsOfMeasure" 
values  stated  are  recommended. 
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Attribute  Name  (from  EDCS) 

Attribute  Definition 

Cardinality 

Data 

Type 

Enumeration  Values  or  Unitst 

Length 

The  length  of  the  longer  of  two 
orthogonal  linear  axes  of  an 
object,  measured  in  the 
horizontal  plane.  For  a  square 
object,  measure  either  axis.  For 
a  round  object,  measure  the 
diameter.  For  a  bridge,  the 
length  is  the  distance  between 
the  bridge  piers. 

1 

float 

meters 

Load_Class_One_Way_Tracked 

The  weight  bearing  capacity  of 
a  bridge  or  bridge  span  for  one 
way  tracked  traffic;  also  known 
as  the  military  load 
classification,  Type  3. 

1 

integer 

Load_Class_One_Way_Wheeled 

The  weight  bearing  capacity  of 
a  bridge  or  bridge  span  for 
oneway  wheeled  traffic;  also 
known  as  the  military  load 
classification,  Type  1. 

1 

integer 

Load_Class_Two_Way_T racked 

The  weight  bearing  capacity  of 
a  bridge  or  bridge  span  for  two 
way  tracked  traffic;  also  known 
as  the  military  load 
classification,  Type  4. 

1 

integer 

Load_Class_Two_Way_Wheeled 

The  weight  bearing  capacity  of 
a  bridge  or  bridge  span  for  two 
way  wheeled  traffic;  also  known 
as  the  military  load 
classification,  Type  2. 

1 

integer 

Overall_Bridge_Height 

The  vertical  distance  measured 

from  the  lowest  point  at  terrain 
or  WATERBODY  level  to  the 

highest  portion  of  bridge 
(including  any  bridge 
superstructure). 

1 

float 

Overhead_Clearance 

The  least  distance  between  a 

terrain  transportation  route  and 
any  obstruction  vertically  above 
it;  the  overhead  clearance. 

1 

float 

P  ri  m  a  ry_M  a  te  ri  a  l_Type 

The  type  of  primary  material 
composition  of  an  object. 

0 

integer 

0002  aluminum 

0006  basalt_masonry 

0025  concrete 

0036  earthen 

0080  masonry 

0109  rock 

0136  steel 

3002  missing 

3006  undesignated 
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Attribute  Name  (from  EDCS) 

Attribute  Definition 

Cardinality 

Data 

Type 

Enumeration  Values  or  Units* 

0013  highway_road 

0021  pedestrian 

Transportation_Use 

The  type  of  primary  user, 
function,  or  authority  of  a 
transportation  system. 

1 

integer 

0024  railroad 

0025  road 

0026  road_and_pedestrian 

0027  road_and_railroad 

3002  missing 

3006  undesignated 

The  characteristic  cross- 

0001  arch 

Tunnel_Cross_Section 

sectional  shape  of  a  tunnel, 

0002  box 

viewed  from  the  ends. 

0003  circular 

The  clearance  below  a  bridge, 
measured  from  the  bridged 

Underbridge_Clearance 

lowest  surface  level  to  the  base 

of  the  lower  of  either  a  cross 

beam  or  the  lowest  bridge  deck; 
the  underbridge  clearance. 

1 

integer 

meters 

Table  A13.  Attributes  of  Terrain  subclass  TRAFFICABILITY_RAILROAD.* 


Attribute  Name  (from  EDCS*) 

Attribute  Definition 

Cardinality 

Data 

Type 

Enumeration  Values  or  Units* 

Bed_Height 

The  height  of  the  bed  of  a  terrain 
transporation  route  above  the 
surrounding  terrain. 

1 

float 

meters 

Existence_Status 

The  status  or  existance  condition  of  an 
object. 

1 

integer 

0001  abandoned 

0012  destroyed 

0013  dismantled 

0043  operational 

0063  under_construction 

*  Subclass:  TRAFFICABILITY_RAILROAD— a  list  of  attributes  associated  with  M-COP  railroad  features,  from  which  mobility 
calculations  can  be  made.  Currently,  this  list  of  attributes  can  stand  alone,  although  if  would  be  desirable  to  merge  it 
with  TRAFFICALBILITY_ROAD  AND  TRAFFICALBILITY_SURFACE. 

t  Some  precipitation  and  state-of-the-ground  attributes  will  also  be  found  in  the  Weather  category;  within  the  Terrain 
category,  these  values  are  related  to  specific  instance  of  the  class,  within  the  Weather  category  they  are  related  to  a 
regional  area.  In  most  cases  the  values  will  be  the  same,  however  not  always,  e.g.  the  snow  cover  depth  based  on  the 
Weather  category  may  be  10  cm,  for  a  region,  for  a  specific  road  within  that  region  the  snow  depth  could  be  zero 
because  it  had  been  plowed.  Mobility  Analysis  would  be  based  on  the  Terrain  category  attribution,  which  must  be 
dynamically  updated  based  on  the  Weather  category  information,  reconnaissance  reports  or  other  services. 

t  The  00S  EDM  does  not  specify  units  of  measure  for  these  attributes.  Each  attribute  needs  a  subclass  "UnitsOfMeasure" 
values  stated  are  recommended. 
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Attribute  Name  (from  EDCS*) 

Attribute  Definition 

Cardinality 

Data 

Type 

Enumeration  Values  or  Units* 

Frozen_Water_Type 

The  type  of  frozen  water  present. 

1 

integer 

0001  ice 

0002  melting_snow_or_ice 

0003  mixed_snow_and_ice 

0004  none_present 

0005  slush 

0006  snow 

0007  snow_over_ice 

Maxi  m  u  m_Sta  nd  i  ng_Water_Depth 

The  maximum  depth  of  non¬ 
flowing/standing  water  within  the  region 
delineated  by  an  object. 

1 

float 

meters 

Multi  pass_Su  rface_Degradation 

The  qualitative  degree  to  which  terrain 
or  a  terrain  transportation  route  has 
been  degraded  by  the  passage  of 

vehicles. 

1 

integer 

0001  heavy 

0002  moderate 

0003  none_present 

Name 

The  textual  identifier  or  code  used  for  an 

object. 

0 

string 

Path_Count 

The  number  of  independent,  parallel 
paths  within  a  terrain  transportation 
route  (e.g.,  tracks  or  lanes),  including 

both  directions. 

1 

integer 

Primary_Material_Type 

The  type  of  primary  material 
composition  of  an  object. 

1 

integer 

0025  concrete_steel 

0136  steel 

0155  wood 

Railroad_Gauge 

The  gauge  of  a  railroad. 

1 

integer 

0002  broad 

3002  missing 

0003  narrow 

0004  normal_country_specific 

0005  us_standard 

Railroad_Power_Source 

The  source  of  electrical  power  for  a 

railroad. 

1 

integer 

0001  electrified  _track 

3002  missing 

0002  non_electrified 

0003  overhead_electrified_ 
non_electrified 

Railroad_Type 

The  type  of  railroad  system  used  to 
support  various  transportation  uses. 

1 

integer 

0001  abandoned 

0002  branchjine 

0003  carjine 

0004  inclined 

0005  logging 

0006  mainjine 

0007  marine 

3002  missing 

0009  monorail 

0010  railroad_in_road 

0012  subway 

0013  tramway 
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Attribute  Name  (from  EDCS*) 

Attribute  Definition 

Cardinality 

Data 

Type 

Enumeration  Values  or  Units* 

Relative_Location 

The  location  of  an  object  relative  to  the 
surrounding  region. 

1 

integer 

0001  above_srf 

0007  below_wtr_body_surface 

3002  missing 

0030  on_terrain 

Snow_Density 

The  density  of  accumulated  snow  on  an 
object. 

0 

float 

(specific  gravity)  or  g/cc 

Snow_Depth 

The  depth  of  snow  and/or  ice  on  the 

terrain. 

0 

float 

meters 

Snow_Only_Depth 

The  depth  of  the  snow,  which  may  be 
over  terrain,  ice,  or  floating  ice. 

0 

float 

meters 

Surface_Material_Type 

The  surface  material  composition  of  an 
object,  excluding  internal  structural 

material. 

1 

integer 

0024  concrete_steel 

0137  steel 

0155  wood 

Surface_Slippery 

Indication  that  a  surface  is  slippery. 
Examples:  wet  grass,  and  wet  clay  soil. 

1 

boolea 

n 

Terrain_Roughness_Root_ 

Mean_Square 

The  roughness  of  terrain  based  on 
elevation  variations,  calculated  using 
the  root-mean-square  (RMS)  value  of  the 
detrended  terrain  elevations  measured 

at  a  spatial  frequency  of  approximately 

0.3  m. 

0 

float 

meters 

Terrain_Trafficability_Fine 

The  categorized  character  of  the  terrain 
as  it  affects  the  movement  of  ground 
forces  (e.g.,  military  units,  vehicles,  or 
infantry)  in  terms  of  a  fine  resolution 
estimate  of  trafficability. 

0 

integer 

0696  id_724 

Terrain_Trafficability_Medium 

The  categorized  character  of  the  terrain 
as  it  affects  the  movement  of  ground 
forces  (e.g.,  military  units,  vehicles,  or 
infantry)  in  terms  of  a  medium 
resolution  estimate  of  trafficability. 

0 

integer 

0001  id_000 

Terrain_Trafficabilty_Coarse 

The  categorized  character  of  the  terrain 
as  it  affects  the  movement  of  ground 
forces  (e.g.,  military  units,  vehicles,  or 
infantry)  in  terms  of  a  coarse  resolution 
estimate  of  trafficability. 

0 

integer 

0005  default 
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Table  A14.  Attributes  of  Terrain  subclass  MANEUVERJJRBAN.* 


Attribute  Name  (from  EDCS) 

Enumeration  Values 

Enumeration  Definitions 

Urban_Terrain_Zone_Typet 

attached_l 

Center  of  older  cities  with  high  concentrations  of  buildings  with 
multiple  floor  levels  (5  to  50).  Buildings  occupy  nearly  all  of 
their  lots  and  are  flush  to  sidewalks  and  they  either  attach  or 
about  neighbors.  Usually  bordered  by  attached_l  and 
discrete_clust_l  zones. 

attached_2 

Buildings  fill  lots  to  their  perimeters,  but  are  not  as  tall  as 
those  in  attached_l.  Buildings  are  attached  or  abutted  to 
neighbors,  are  flush  to  streets,  and  are  typically  5  to  10  floor 
levels.  Land  use  is  mainly  apartment  houses  with  some  hotels 

and  offices. 

attached_3 

Attached  or  abutted  individual  buildings  (for  example:  row 
houses),  typically  of  1  to  4  floor  levels  and  most  often 
residential.  Buildings  have  little  or  no  setback  from  sidewalk 
and  they  usually  have  a  narrow  back  yard. 

attached_4 

Attached  or  abutted  buildings,  2  to  10  floor  levels,  flush  to  the 
street  with  no  setback  or  side  set.  Buildings  have  industrial  or 
storage  functions  with  little  space  for  parking.  Non-built-upon 
space  is  primarily  for  storage  of  material. 

attached_5 

Attached  or  abutted  buildings,  along  commercial  ribbon 
streets.  Typically  1  to  5  floor  levels,  and  old  in  age  (newer 
types  are  typically  of  the  discrete_clust_5  zone),  with  no 
setback  from  sidewalks.  The  buildings  often  have  a 
commercial  function  on  the  ground  floor,  with  apartments 

above. 

attached_6 

Attached  building  or  buildings,  1  to  7  floor  levels;  often  a  single 
institutional  land  use  along  a  street  otherwise  occupied  by 
office  buildings  or  stores,  e.g.,  a  church,  government  building, 
or  a  hospital.  This  is  in  effect  a  single  instance  of  a  differing 
building  rather  than  a  zone  of  multiple  buildings. 

attached_buildings 

Attached  buildings  of  an  unknown  type  or  function. 

close_set_buildings 

Close-set  buildings  of  an  unknown  type  or  function. 

discrete_clust_l 

Newer  (post  1950)  high-rise  buildings  (20  to  50  floor  levels) 
that  often  have  "skins"  of  some  decorative  material  (for 
example:  glass).  Typical  use  is  for  office  buildings,  while  some 
are  hotels.  Buildings  are  spaced  at  approximately  13  m. 

discrete_clust_2 

Close-set  apartment  buildings  (3  to  10  floor  levels)  with  some 
set  back  from  the  lot  boundary.  Buildings  are  usually  long  and 
narrow  with  the  narrow  end  to  the  street.  Maximum  spacing  of 
the  buildings  is  13  m. 

discrete_clust_3 

Common  single  family  detached  structures  occupying  a 
minimum  amount  of  land.  Houses  are  set  back  from  the  street, 
but  have  narrow  separations  between  them,  and  narrow  back 
yards.  Maximum  spacing  of  the  buildings  is  13  m,  and 
buildings  are  typically  1  to  3  floor  levels. 

discrete_clust_4 

Narrow,  close-set  buildings  (2  to  10  floor  levels)  adjoining 

*  Subclass  MANEUVER_URBAN:  A  group  of  attributes  for  Built-Up  area  features,  used  for  Maneuver  Analysis  in  urban 
Terrain,  these  attributes  are  from  the  EDCS,  the  urban  zone  types  (UTZ)  are  based  on  Liu  and  Ellefsen  (1996),  and  the 
street  patterns  from  FACC  (DGIWG  2000). 

t  Definition:  The  type  of  an  UTZ  based  on  the  characterization  of  buildings  and  their  density. 
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Attribute  Name  (from  EDCS) 

Enumeration  Values 

Enumeration  Definitions 

railway  tracks  with  docks  for  access  by  ground  vehicles. 

Buildings  are  often  long  and  narrow,  with  the  narrow  end 
abutting  the  railway  tracks.  Maximum  spacing  of  the  buildings 

is  13  m. 

discrete_clust_5 

Detached  buildings  (1  to  5  floor  levels)  set  back  from  the 
street  to  provide  parking  and  access.  These  buildings  often 
exhibit  store  windows  at  front.  The  majority  of  the  terrain  is 
used  for  parking  ground  vehicles.  Maximum  spacing  of  the 
buildings  is  13  m. 

discrete_clust_6 

Master  planned  development  with  specifically  set  buildings  of 

1  to  7  floor  levels,  and  vegetated  sites  that  provide  elegantly 
designed  facilities  and  a  sense  of  openness.  Uses  include 
schools,  colleges,  hospitals,  or  churches.  Maximum  spacing  of 
the  buildings  is  13  m. 

discrete_clust_8 

Outer  city. 

discrete_open_l 

Large  buildings  (1  to  4  floor  levels)  with  a  distinctive  lack  of 
exterior  windows,  internally  partitioned  into  individual  retail 
facilitys,  and  surrounded  by  extensive  vehicle  lots.  The  main 
building  is  normally  located  in  the  center  or  at  the  rear  of  the 
vehicle  lot,  with  vehicle  lots  consuming  approximately  70  %  of 
the  terrain.  Typical  use  is  for  shopping  malls, 
professional/business  parks.  Spacing  between  buildings  is  13 
m  or  greater. 

discrete_open_2 

Evenly  spaced  buildings  in  planned  settings  supporting  fairly 
high  population  densities  yet  providing  collective  open  space 
between  buildings.  Intervening  ground  space  is  landscaped  or 
vehicle  lots.  Typical  spacing  between  buildings  is  13  m  with 
buildings  being  2  to  40  floor  levels. 

discrete_open_3 

Single  family  detached  buildings  occupying  a  minimum 
amount  of  land.  Buildings  are  set  back  on  all  sides.  This  zone 
is  similar  to  discrete_clust_3  with  the  difference  being  that 
discrete_open_3  signifies  more  space  between  buildings,  and 
often  more  vegetation.  Spacing  between  buildings  is  13  m  or 
greater,  with  buildings  being  1  to  3  floor  levels. 

discrete_open_4 

Modern  industrial  space  with  access  for  trucks  and  parking 
space,  typically  used  for  industry  or  storage.  Buildings  are 
widely  separated  and  have  paved  surfaces  around  them. 

Spacing  between  buildings  s  is  13  m  or  greater,  and  buildings 

are  1  to  4  floor  levels. 

discrete_open_5 

Modern,  large,  commercial  buildings  (1  to  5  floor  levels)  with 
large  vehicle  lots  and  located  along  wide  streets;  Discrete- 
open-5.  Typically  used  for  large  retail  facilitys,  equipment, 
automobile  dealerships,  and  restaurants.  Space  between  the 
buildings  is  13  m  or  greater. 

discrete_open_6 

Sizeable,  master  planned  development  with  large  buildings 
and  maintained  heavily  vegetated  sites  that  provide  elegantly 
designed  facilities  and  a  sense  of  openness.  Often  used  for 
schools,  colleges,  hospitals,  churches,  and  administrative 
facilities.  Spacing  between  buildings  is  13  m  or  greater,  and 
buildings  are  typically  1  to  7  floor  levels. 

does_not_conform 

Configuration  does  not  conform  to  any  urban  terrain  zone. 

widely_spaced_buildings 

Widely  separated  detached  buildings  of  an  unknown  type  or 

function. 
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Attribute  Name  (from  EDCS) 

Enumeration  Values 

Enumeration  Definitions 

U  rba  n_Street_Pattern  ’ 

curvilinear_cluster 

Curvilinear  cluster  with  limited  access  from  outside. 

irreg_grid 

Rectangular  or  irregular  grid. 

irreg_radial 

Concentric  or  radial  irregular. 

linear_strip 

Linear  strip. 

mixed_cluster 

Mixed  curvilinear_cluster  and  rectangular  grid. 

mixed_grid 

Mixed  concentric  or  radial  and  rectangular  grid. 

mixed_radial 

Mixed  curvilinear_cluster  and  concentric  or  radial. 

reg_grid 

Rectangular  or  regular  grid. 

reg_radial 

Concentric  or  radial  regular. 

Definition:  The  predominant  geometric  configuration  of  streets  found  within  a  delineated  terrain  surface  region. 
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APPENDIX  B:  M-COP  OBSTACLE  CATEGORY 

Table  Bi  presents  the  enumeration  values  for  a  Feature__Type  attribute  of 
each  of  the  Obstacle  classes.  These  enumeration  values  are  the  same  as 
their  sources.  For  reader  ease  the  formats  have  been  changed  to  the 
nomenclature  chosen  for  this  report.  The  intent  for  the  M-COP  is  to  use 
the  OOS  EDM  values;  the  other  sources  are  shown  only  for  comparison. 
The  terms  area,  line,  directed_line,  3d__line,  and  point  denote  the 
geometry  type. 


Table  Bl.  Enumeration  values  for  Feature_Type  attribute  of  each  of  the  Obstacle  classes. 


JC3IEDM  geographic 
or  facility  category 
code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

X 

abatis 

X 

antitank_wall 

X 

barrier  line 

barrier 

biological  ly_co  ntaminated_area 

chem  ica  lly_conta  m  i  nated_a  rea 

X 

cross_country_barrier  line 

belt_obstacle 

X 

dragon_teeth  line, 

dragon_teeth  point 

dragon_teeth 

fixed_and_prefabricated_antitank_  obstacles, 
tetrahedrons, 

dragon_teeth_and_other_similar_obstacles, 

X 

moveable_antitank_obstacles,  tetrahedrons, 
dragon_teeth_and_other_similar_obstacles 

X 

engineer_trench  directed Jine 

trench 

completed_antitiank_ditch, 

antitank_ditch_under_construction, 

a  ntita  n  k_d  itch_rei  nforced_with_antita  n  k_m  i  n 

es 

X 

fence  line 

fence 

unspecified,  single_fence,  double_fence, 
double_apron_fence,  low_wire_fence, 
high_wire_fence,  single_strand_concertina, 
double_strand_concertina, 
triple_strand_concertina, 

field_expedient_obstacle  point 

hedgerow  line 

hedgerow 

log_obstacle  point 
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JC3IEDM  geographic 
or  facility  category 
code 

OOS  EDM  (version  1.7) 

FACC 

(DGIWG  2000) 

FM  21-31 

(HQDA  1961) 

X 

minefield  area 

booby_trap,  antipersonnel_mines, 
antitank_mine, 

antitank_mine_with_anti_handling_device, 
unspecified_mine,  mine_cluster, 
wide_area_mine,  completed_minefield, 
planned_minefield,  antipersonnel_minefield, 
antitank_minefield, 
antitank_minefield_with_gap, 
scatterable_mines_minefield_with_self_destr 
uct,  antipersonnel_ 

minefield_reinforced_with_scatterable_mines, 

scatterable_ 

minefield_(antitank_mines)_with_self_ 
destruct,  mined_area,  executed 
_volcano_antitank_minefield 

miscellaneous_obstacle 

obstacle_line 

obstacle_zone 

obstacle_restricted_area 

radioactive_area 

X 

rock_drop  point 

terrain_crater  point 

X 

terrain_cut  directed Jine 

unexploded_ordnance_area 

X 

vehicle_barrier  point 

X 

wire_obstacle  line 

Table  B2.  Attributes  of  selected  Obstacle  category  classes. 


Class  (from  EDCS) 

Attribute  Name 

Attribute  Description 

Enumeration  Values 

BARRIER 

Completion_Percentage 

The  extent  of  completion  for  an  object 

in  terms  of  fractional  ascension  from 
start  of  construction  to  completion  of 

construction. 

General_Damage_Fraction 

The  extent  of  physical  injury/damage 
to  an  object  in  terms  of  fractional 
degradation  from  a  healthy  state. 

1/4:  Slight  Injury/Damage 

2/4:  Moderate  Injury/Damage 

3/4:  Heavy  Injury/Damage 

4/4:  Fatally  Injured  or 
Completely  Destroyed 

H  e  ight_Above_S  u  rf  a  ce_Level 

The  distance  measured  from  the 

highest  point  at  surface  level  to  the 
lowest  point  of  an  object  below  the 
surface,  as  a  positive  number. 

Numeric_Object_ldentifier 

The  numeric  identifier  of  an  object. 
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Class  (from  EDCS) 

Attribute  Name 

Attribute  Description 

Enumeration  Values 

Prepared_Explosive_ 

Destruction_ 

Completion_Fraction 

The  extent  to  which  an  object  (e.g.,  a 
structure  or  terrain  obstacle),  has  been 
prepared  for  destruction  by  explosives 
in  terms  of  fractional  completion. 

1/4:  Partially  Prepared 

2/4:  Half  Prepared 

3/4:  Mostly  Prepared 

4/4:  Completely  Prepared 

Surface_Slope 

The  maximum  slope  (rise/run)  of  the 
surface  of  an  object. 

CROSS_COUNTRY_ 

BARRIER  LINE 

Completion_Percentage 

The  extent  of  completion  for  an  object 

in  terms  of  fractional  ascension  from 
start  of  construction  to  completion  of 

construction. 

Depth_Below_Surface_Level 

The  distance  measured  from  the 

highest  point  at  surface  level  to  the 
lowest  point  of  an  object  below  the 
surface,  as  a  positive  number. 

Forcejdentifier 

A  textual  identify  of  a  military  or 

civilian  force. 

General_Damage_Fraction 

The  extent  of  physical  injury/damage 
to  an  object  in  terms  of  fractional 
degradation  from  a  healthy  state. 

1/4:  Slight  Injury/Damage 

2/4:  Moderate  Injury/Damage 

3/4:  Heavy  Injury/Damage 

4/4:  Fatally  Injured  or 
Completely  Destroyed 

FI  e  ight_Above_S  u  rf  a  ce_Level 

The  height  measured  vertically  from 

the  terrain  or  WATERBODY  surface.  For 

physical  objects,  measured  from  the 
lowest  point  of  the  object  base 
(downhill  side/downstream  side)  to  the 
highest  point  of  the  object. 

Prepared_Explosive_ 

Destruction_Completion_Fractio 

n 

The  extent  to  which  an  object  (e.g.,  a 
structure  or  terrain  obstacle),  has  been 
prepared  for  destruction  by  explosives 
in  terms  of  fractional  completion. 

1/4:  Partially  Prepared 

2/4:  Half  Prepared 

3/4:  Mostly  Prepared 

4/4:  Completely  Prepared 

Terrain_Obstacle_Type 

The  type  of  a  terrain  obstacle. 

0001  abatis 

0002  antipersonnel_wire 

0003  antitank_ditch 

0004  antivehicle_wire 

0007  craters 

0014  dragon_teeth 

0018  hedge_hogs 

0019  linear_concrete_barrier 

3002  missing 

0024  road_block_or_crib 

0025  rubble_missing 

0027  tetrahedrons 

3006  undesignated 

Surface_Slope 

The  maximum  slope  (rise/run)  of  the 
surface  of  an  object. 
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Class  (from  EDCS) 

Attribute  Name 

Attribute  Description 

Enumeration  Values 

Width 

The  length  of  the  shorter  of  two 
orthogonal  linear  axes  of  an  object, 
measured  in  the  horizontal  plane.  For  a 
square  object,  measure  either  axis.  For 
a  round  object,  width  is  equal  to 
length.  For  a  bridge,  the  width  is  the 
measurement  perpendicular  to  the  axis 
between  the  bridge  piers. 

ENGINEER_TRENCH 
directed Jine 

Trafficablity_Surface 

From  Terrain  category. 

Trafficability_Drygap 

From  Terrain  category. 

Completion_Percentage 

The  extent  of  completion  for  an  object 

in  terms  of  fractional  ascension  from 

start  of  construction  to  completion  of 

construction. 

Overall_Vertical_Dimension 

The  overall  vertical  dimension  that 

includes  both  above  and  below. 

Terrain_Gap_Width 

The  minimum  horizontal  bridging 

distance  between  the  banks  of  a 

localized  terrain  depression,  as 
measured  perpendicular  to  the  center 
line  of  its  length  along  the  terrain 
depression. 

Terrain_Obstacle_Type 

The  type  of  a  terrain  obstacle. 

0003  antitank_ditch 

0011  ditch 

0012  ditch_with_berm 

0016  emplaced_boulder 

Width 

The  length  of  the  shorter  of  two 
orthogonal  linear  axes  of  an  object, 
measured  in  the  horizontal  plane.  For  a 
square  object,  measure  either  axis.  For 
a  round  object,  width  is  equal  to 
length.  For  a  bridge,  the  width  is  the 
measurement  perpendicular  to  the  axis 
between  the  bridge  piers. 

MINEFIELD 

Traff  i  ca  b  1  i  ty_S  u  rf  a  ce 

From  Terrain  category. 

Case_Burial_Fraction 

The  fraction  of  an  equipment  case  that 

is  buried  beneath  the  terrain  or 

WATERBODY  floor. 

0/4:  On-surface 

2/4:  Half-buried 

4/4:  Completely  buried 

Completion_Percentage 

The  extent  of  completion  for  an  object 

in  terms  of  fractional  ascension  from 

start  of  construction  to  completion  of 

construction. 

Duration_Overview 

The  quantity  of  time  in  a  gross  sense 
that  the  object  may  be  assumed  to  be 

active. 

0001  infinite 

0002  long 

0003  medium 

0005  none 

0099  other 

0004  short 
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Class  (from  EDCS) 

Attribute  Name 

Attribute  Description 

Enumeration  Values 

Explosive_Mine_Type 

The  type  of  an  explosive  mine. 

0002  antipersonnel 

0003  antitank 

0004  antitank_smart 

0006  aquatic_bottom 

0007  aquatic_buried 

0009  aquatic_floating 

0011  aquatic_moored 

0012  aquatic_proud 

0015  decoy 

3002  missing 

0019  mixed 

3006  undesignated 

Forcejdentifier 

A  textual  identify  of  a  military  or  civilian 
force. 

General_Damage_Fraction 

The  extent  of  physical  injury/damage 
to  an  object  in  terms  of  fractional 
degradation  from  a  healthy  state. 

1/4:  Slight  Injury/Damage 

2/4:  Moderate  Injury/Damage 

3/4:  Fleavy  Injury/Damage 

4/4:  Fatally  Injured  or 
Completely  Destroyed 

Mine_Allegiance 

The  military  allegiance  of  the  force 
responsible  for  the  creation  or 
maintenance  of  an  EXPLOSIVE_MINE. 

0001  alternate_l 

0002  alternate_2 

0003  alternate_3 

0004  alternate_4 

0005  alternate_5 

0006  alternate_6 

0007  alternate_7 

0008  alternate_8 

0009  alternate_9 

0010  friend 

0011  hostile 

3002  missing 

0012  neutral 

Mine_Density 

The  areal  density  of  explosive  mines 
within  a  minefield.  Units  of  1  mine/m2. 

Minefield_Marking_Type 

Specifies  by  whom  and  how  the 

MINEFIELD  is  marked. 

0003  all_sides 

0997  data_withheld 

0002  marked 

0998  not_applicable 

0999  other 

0001  unmarked 

Numeric_Object_ldentifier 

The  numeric  identifier  of  an  object. 

Prepared_Explosive_ 

Destruction_Completion_Fractio 

n 

The  extent  to  which  an  object  (e.g.,  a 
structure  or  terrain  obstacle),  has  been 
prepared  for  destruction  by  explosives 
in  terms  of  fractional  completion. 

1/4:  Partially  Prepared 

2/4:  Half  Prepared 

3/4:  Mostly  Prepared 

4/4:  Completely  Prepared 
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APPENDIX  C:  M-COP  WEATHER  CATEGORY 


Table  Cl.  Weather  class:  PRECIPITATION. 


Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

Accum_Precip 

The  depth  of  PRECIPITATION 
(water-equivalent)  that 

accumulated  over  a 

measurement  period  of  time. 

IMETS,  EDCS 

Accum_Precip_6_Hour 

The  depth  of  PRECIPITATION 
(water-equivalent)  that 

accumulated  over  a  6-hr 
period. 

IMETS,  EDCS 

Accum_Precip_3_Hour 

The  depth  of  PRECIPITATION 
(water-equivalent)  that 

accumulated  over  a  3-hr 

period. 

IMETS,  EDCS 

Accum_Precip_6_Hour 

The  depth  of  PRECIPITATION 
(water-equivalent)  that 

accumulated  over  a  6-hr 

period. 

IMETS,  EDCS 

Accum 

_Precip_24_Hour 

The  depth  of  PRECIPITATION 
(water-equivalent)  that 

accumulated  over  a  24-hr 

period. 

IMETS,  EDCS 

Hail_Size 

The  diameter  of  the  largest 

hailstone  observed. 

JMCDM 

Precipitationjntensity 

Intensity  of  PRECIPITATION. 

0 

none 

No  PRECIPITATION  is  present. 

IMETS,  EDCS 

1 

light 

For  rain  and  ice_pellets:  up  to 
2.54  mm  per  hr  or  up  to  0.254 

mm  in  6  min.  For  snow  and 

drizzle:  visibility  greater  than 

800  m. 

IMETS,  EDCS 

2 

moderate 

For  rain  and  ice_pellets:  more 
than  2.54  mm  up  to  7.62  mm 
per  hr  or  more  than  0.254  mm 
up  to  0.762  mm  in  6  min.  For 
snow  and  drizzle:  visibility 

moderate. 

IMETS,  EDCS 

3 

heavy 

For  rain  and  ice_pellets:  more 
than  7.62  mm  per  hr  or  more 

than  0.7  62  mm  in  6  min.  For 

snow  and  drizzle:  visibility  less 
than  or  equal  to  400  m. 

IMETS,  EDCS 
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Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

Precipitation_Phase 

The  state  (liquid/solid 
disposition)  of  precipitable 

water. 

1 

liquid 

Composed  of  only  liquid 
components. 

EDCS 

2 

mixed 

Composed  of  both  liquid  and 
solid  components. 

EDCS 

3 

solid 

Composed  of  frozen 
components. 

EDCS 

Precipitation_Rate 

The  rate  of  PRECIPITATION. 

IMETS,  EDM- 
AOS,  EDCS 

Precipitation_Type 

The  type  of  PRECIPITATION. 

1 

diamond_ 

dust 

solid_precipitation  that  falls 
from  a  clear  sky  in  very  small 
crystals  of  ice,  often  so  tiny  that 
they  appear  to  be  suspended  in 

the  air. 

EDCS 

2 

drizzle 

Fairly  uniform  PRECIPITATION 
in  very  fine  droplets  (outside 
diameter  less  than  0.5  mm) 
that  are  located  very  close  to 
one  another  and  are  falling 

from  a  cloud. 

EDCS,  IMETS 

3 

freezing_ 

drizzle 

drizzle  that  falls  in  liquid  form 
but  freezes  upon  impact  to 
form  a  coating  of  ice_glaze  on 
the  land  and  on  exposed 
objects. 

EDCS 

4 

freezing. 

rain 

rain  that  falls  in  liquid  form  but 
freezes  upon  impact  to  form  a 
coating  of  ice_glaze  on  the  land 
and  on  exposed  objects. 

EDCS,  IMETS 

5 

graupel 

A  form  of  frozen 

PRECIPITATION  consisting  of 
snowflakes  or  ice_crystals  and 
supercooled  water  droplets 
frozen  together. 

EDCS 

6 

hail 

solid_precipitation  of  either 
transparent  or  partly  or 
completely  opaque  particles  of 
ice  (hailstones),  usually 
spherical,  conical,  or  irregular 

in  form  and  of  outside  diameter 

generally  between  5  and  50 
mm,  that  falls  from  a  cloud 
either  separately  or 
agglomerated  into  irregular 
lumps. 

EDCS 

144 


ERDC  TR-07-4 


Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

7 

ice_ 

crystals 

A  fall  of  any  one  of  a  number  of 
macroscopic  crystalline  forms 
of  ice,  including  hexagonal 
columns  and  platelets,  dentritic 
crystals,  needles  or  a 

combination  of  these  forms. 

EDCS 

8 

ice_pellets 

solid_precipitation  of 
transparent  or  translucent 
particles  of  ice  that  are 
spherical  or  irregular,  rarely 
conical,  and  that  have  an 

outside  diameter  of  5  mm  or 

less. 

EDCS 

9 

liquid_ 

precip_ 

freezing 

Liquid  PRECIPITATION  that 
freezes  upon  contact  to  form  a 
coating  of  ice_glaze  upon  the 
land  and  exposed  objects. 

EDCS,  IMETS 

10 

liquid 

_precip_ 

not_freez- 

ing 

Liquid  PRECIPITATION  that 
does  not  freeze  upon  contact. 

EDCS,  IMETS 

11 

no_precip 

No  PRECIPITATION. 

EDCS,  IMETS 

12 

precip 

Unspecified  PRECIPITATION. 

EDCS 

13 

rain 

PRECIPITATION  of  particles  of 
liquid  water  either  in  the  form 
of  drops  of  more  than  5  mm  in 
outer  diameter  or  in  the  form  of 

widely  scattered  drops. 

EDCS,  IMETS 

14 

rain_and_ 

drizzle 

PRECIPITATION  consisting  of  a 

mixture  of  rain  and  drizzle. 

EDCS 

15 

rain_and_ 

hail 

PRECIPITATION  consisting  of  a 

mixture  of  rain  and  hail. 

EDCS 

16 

rain_and_ 

snow 

PRECIPITATION  consisting  of  a 

mixture  of  rain  and  snow. 

EDCS 

17 

sleet 

snow  that  has  partially  melted 
on  its  fall  to  the  ground. 

EDCS 

18 

small_hail 

hail  with  an  outside  diameter 

less  than  0.64  cm  which  is  a 
form  of  ice_pellets. 

EDCS 

19 

snow 

solid_precipitation  composed 
of  white  or  translucent  crystals 
of  ice  that  are  chiefly  in 
complex  branch  hexagonal 
form  and  are  often 

agglomerated  into  snowflakes 
or  the  layer  formed  by  them  on 

the  land. 

EDCS,  IMETS 
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Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

20 

snow_ 

grains 

solid_precipitation  of  very  small 
opaque  white  particles  of  ice 

that  fall  from  a  cloud  and  are 

fairly  flat  or  elongated  with 
outside  diameters  generally 
less  than  1  mm;  the  solid 
equivalent  of  drizzle. 

EDCS 

21 

snow_ 

pellets 

PRECIPITATION  of  white  and 

opaque  particles  of  ice,  which 

fall  from  a  cloud  and  which  are 

generally  conical  or  rounded, 
with  diameters  attaining  as 

much  as  5  mm. 

EDCS 

22 

solicL 

precip 

PRECIPITATION  of  ice. 

EDCS,  IMETS 

Snow_Accumulation 

_Depth 

The  frozen  or  freezing 

PRECIPITATION  that 

accumulates  during  a  period 

of  time. 

EDCS,  JMCDM 

Snow_Accumulation 

_Condition_Code 

The  code  that  denotes 

specific  conditions 

associated  with  the 

measurement  of  the  depth  of 

snow  accumulation. 

0 

none 

JMCDM 

1 

measurem 

ent_ 

impossible 

_or_ 

inaccurate 

JMCDM 

2 

snow_ 

cover_not 

continuou 

s 

JMCDM 

3 

trace 

JMCDM 

4 

measurea 

ble 

JMCDM 

Snow_Age 

The  time  difference  between 

the  reference  date  and  the 

date  of  the  last  measurable 

snow  precipitation. 

EDCS 

Snow_Density 

The  density  of  accumulated 
snow  precipitation  on  an 
object. 

edcs 
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Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

Snow_Depth' 

A  frozen  accumulation  of 

PRECIPITATION  on  the 

ground. 

IMETS,  EDM- 
AOS,  EDCS, 

JMCDM 

Snow_Depth_Category 

The  categorical  (coded) 

amount  of  snow  that  has 

accumulated. 

1 

none_ 

present 

No  snow  present. 

EDCS 

2 

trace 

Light  (trace)  dusting  of  snow  in 
which  the  visual  appearance  of 
the  original  landscape 
predominates,  less  than  1  cm 

accumulation. 

EDCS 

3 

slight 

Dusting  of  snow  in  which  the 

white  color  of  the  snow 

predominates  but  the  visual 
appearance  of  the  original 
landscape  is  still  evident;  1-2 

cm  accumulation. 

EDCS 

4 

moderate 

Snow_Depth_Dimension  of  2  to 

5  cm. 

EDCS 

5 

moderate_ 
to_  heavy 

Snow_Depth_Dimension  of  5  to 

20  cm. 

EDCS 

6 

heavy 

Snow_Depth_Dimension 
greater  than  20  cm. 

EDCS 

Snow_Depth_ 

Condition_Code 

The  code  that  denotes 

specific  conditions 

associated  with  the 

measurement  of  snow  in  a 

PRECIPITATION  observation. 

0 

none 

JMCDM 

1 

measurem 

ent_ 

impossible 

_  or_ 

inaccurate 

JMCDM 

2 

snow_ 

cover_not 

continu¬ 

ous 

JMCDM 

3 

trace 

JMCDM 

4 

measurea 

ble 

JMCDM 

Snow_Depth_Dimen- 

sion 

Depth  of  snow  and  ice  on  the 
ground. 

JMCDM 

Snow_Depth  pertaining  to  meteorological  conditions. 
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Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

Snow_Depth_ 
Equivalent_Water_Dep 
th_  Dimension 

The  depth  of  the  liquid 

content  of  solid 

PRECIPITATION  that  has 

accumulated  on  the  ground. 

JMCDM 

Snow_Drift_Height_ 

Dimension 

Maximum  height  of  snow 

drifts. 

JMCDM 

Snow_Melting_Rate 

Estimated  melting  rate  of 
snow  on  the  ground. 

JMCDM 

Thunderstormjntensit 

y 

The  intensity  of  a 

thunderstorm  as  determined 

by  its  Precipitation_Rate. 

1 

light 

Up  to  2.54  mm  per  hr; 

maximum  0.254  mm  in  6  min. 

EDCS 

2 

moderate 

More  than  2.54  mm  up  to  7.62 
mm  per  hr;  more  than  0.254 
mmupto0.762mmin6min. 

EDCS 

3 

heavy 

More  than  7.62  mm  per  hr; 

more  than  0.762  mm  in  6  min. 

EDCS 

Thunderstorm_Present 

An  indication  that  a  thunder 

storm  is  present. 

0 

not_ 

present 

EDCS 

1 

present 

EDCS 

Thunderstorm_Probabi 

lity 

The  probability  of  the 

occurrence  of  a 

thunderstorm. 

EDCS,  JMCDM 

Table  C2.  Weather  class:  ATMOSPHERE. 


Subclass 

Attribute  Name 

Attribute  Definition 

Source 

AIR_TEMPERATURE 

2m_Air_Temperature 

The  temperature  of  the  air  at  2  m. 

IMETS, 

JMCDM 

Height_Of_Measurement 

Height  AIR_TEMPERATURE  was  taken. 

JMCDM 

Maximum_Air_Temperature 

The  maximum  AIR_TEMPERATURE  that 
occurred  at  a  given  LOCATION  during  a 
specific  Time_Period. 

EDCS, 

JMCDM 

Maximum_Air_Temperature_Period 

The  Time_Quantity  for  which  a 
Maximum_Air_Temperature  was 

recorded. 

EDCS, 

JMCDM 

Mean_Air_Temp 

The  mean  AIR_TEMPERATURE. 

EDCS, 

JMCDM 

Mean_Air_Temp_Clim 

The  mean  historical  (climatology) 
AIR_TEMPERATURE. 

EDCS 

Mean_Air_Temp_Clim_Std_Dev 

The  standard  deviation  of 

Mean_Air_Temp_Clim  measurements. 

EDCS 

Mean_Air_Temp_Difference_Clim 

The  historical  (climatology)  quantity  of 
mean  difference  between  the 

Mean_Air_Temperature  at  an  initial 
time  and  the  Mean_Air_Temperature 

at  an  offset  from  that  time. 

EDCS 
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Subclass 

Attribute  Name 

Attribute  Definition 

Source 

Mean_Air_Temp_Min_Difference_Clim 

The  historical  (climatology)  quantity  of 

maximum  difference  between  the 

Mean_Air_Temperature  at  an  initial 
time  and  the  Mean_Air_Temperature 
at  an  offset  from  that  time. 

EDCS 

Minirnum_Air_Temperature 

The  lowest  AIR_TEMPERATURE 
attained  during  a  Time_Quantity. 

EDCS, 

JMCDM 

Minimum_Air_Temperature_Period 

The  Time_Quantity  for  which  a 
Minimum_Air_Temperature  was 

recorded. 

EDCS, 

JMCDM 

Surface_Air_Temperature 

AIR_TEMPERATURE  at  the  surface. 

IMETS, 

JMCDM 

Wind_Chill_lndex 

The  temperature  with  nearly  still  air 
that  (ideally)  produces  the  same  rate 
of  heat  loss  from  the  human  body  as 
the  given  combination  of  temperature 
and  wind  speed. 

EDCS 

Wind_Chill_Temperature_lndex 

A  means  of  quantifying  the  combined 
effect  of  low  AIR_TEMPERATURE  and 
Wind_Speed  on  the  body  temperature 
of  humans  that  may  result  in 
hypothermia. 

EDCS 

DEW_POINT 

Dew_Point_Depression 

The  difference  between 

AIR_TEMPERATURE  at  a  location  and 
the  Dew_Point_Temperature  at  that 

location. 

EDCS 

Dew_Point_Temperature 

The  temperature  to  which  a  given 
parcel  of  air  must  be  cooled  at 
constant  atmospheric  pressure  and 
water  vapor  content  for  saturation  to 

occur. 

EDCS, 

JMCDM 

Mean_Dew_Point_Temperature 

The  mean  Dew_Point_Temperature. 

EDCS, 

JMCDM 

HUMIDITY 

Absolute_Humidity 

The  ratio  of  the  mass  of  water  vapor  to 
the  volume  occupied  by  the  mixture  of 
water  vapor  and  dry  air. 

EDCS 

Relative_Humidity 

The  ratio  of  vapor  pressure  to 
saturation  vapor  pressure,  where 
vapor  pressure  is  the  pressure  exerted 
by  the  molecules  of  water  vapor  and 
saturation  vapor  pressure  is  the 
pressure  exerted  by  molecules  of  water 
vapor  in  air  that  has  attained 

saturation 

EDCS 

Specific_Humidity 

The  ratio  of  the  mass  of  water  vapor  to 

the  total  mass  of  a  volume  of  moist  air. 

EDCS 

Relative_Humidity_Minimum_Temperature 

The  Relative_Humidity  at  the  time  of 
the  lowest  AIR_TEMPERATURE. 

EDCS 

LIGHTNING 

Lightning_Loc_Err_Ellps_Angle 

The  Geodetic_Azimuth  of  the  semi¬ 
major  axis  of  the  error  ellipse  of  the 

LOCATION  of  a  stroke  of  LIGHTNING. 

EDCS 
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Subclass 

Attribute  Name 

Attribute  Definition 

Source 

Lightning_Loc_Err_Major_Axis 

The  length  of  the  semi-major  axis  of 
the  error  ellipse  at  the  LOCATION  of  a 
stroke  of  LIGHTNING. 

EDCS 

Ughtn  i  ng_Loc_Err_M  i  nor_Axis 

The  length  of  the  semi-minor  axis  of 
the  error  ellipse  at  the  LOCATION  of  a 

stroke  of  LIGHTNING. 

EDCS 

Lightning_Probability 

The  probability  that  LIGHTNING  will 

occur. 

EDCS 

Route_Weather_Type 

The  weather  conditions  under  which  a 

land  transportation  route  is  passable 
or  remains  open  (has  enumerations). 

EDCS 

Table  C3.  Weather  class:  WIND. 


Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

Dust_Production_Rate 

A  number  between  0  and  1 

inclusive  representing  the  linearly 
scaled  fraction  of  the  production  of 
dust  at  an  object  that  has  been 
induced  by  ground  movement  or 

surface  wind. 

EDCS 

Maximum 

_Wind_Gust_Spread 

The  maximum  Wind_Gust_Spread. 

EDCS,  JMCDM 

Maximum_Wind_Speed 

The  maximum  or  peak 

Wind_Speed  including  gusts. 

EDCS,  JMCDM 

Mean_Wind_Speed 

The  mean  Wind_Speed. 

EDCS,  JMCDM 

Mean_Wind_Speek_Std_ 

Dev 

The  standard  deviation  of 

Mean_Wind_Speed 

measurements. 

EDCS 

Surface_Wind_Speed 

The  Wind_Speed  10  m  above  the 

earth. 

EDCS 

Wind_Calm_Fraction 

_Climatology 

The  historical  (climatology)  fraction 
of  calm  Wind_Speeds  (less  than 
2.575  m/s). 

EDCS 

Wind_Category 

A  categorization  of  wind  based  on 
Wind_Speed  and  its  variability. 

1 

calm 

The  absence  of  air  motion 

or  Wind_Speeds  is  less 
than  1.582  kph. 

EDCS,  JMCDM 

2 

no_ 

gusts 

No  gusts. 

EDCS,  JMCDM 

3 

squall 

An  abrupt  and  large 
increase  in  Wind_Speed 

with  a  duration  on  the 

order  of  minutes  which 

diminishes  rather  suddenly. 

EDCS,  JMCDM 

4 

variable 

Wind  that  changes 
direction  frequently. 

EDCS,  JMCDM 

Wind_Direction 

The  Geodetic_Azimuth  of  the 

direction  from  which  the  wind  is 

blowing. 

EDCS,  JMCDM 
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Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

Wind_Direction_Climatol- 

ogy 

The  mean  historical  (climatology) 
Wind_Direction. 

EDCS,  JMCDM 

Wind_Direction_Octant_ 

Climatology 

The  historical  (climatology) 
Wind_Direction  categorized  by 
cardinal  vector  octant  (45  arc 
degree  sector  centered  on  a 
cardinal  direction). 

1 

north 

EDCS 

2 

north_ 

east 

EDCS 

3 

east 

EDCS 

4 

south_ 

east 

EDCS 

5 

south 

EDCS 

6 

south_ 

west 

EDCS 

7 

west 

EDCS 

8 

north_ 

west 

EDCS 

Wind_Direction_Octant_ 

Fraction 

A  number  between  0  and  1 

inclusive  representing  the  linearly 
scaled  fraction  of  observations 

reporting  Wind_Directions  within  a 
cardinal  vector  octant  (a  45  arc 
degree  sector  centered  on  a 
cardinal  direction). 

EDCS,  JMCDM 

Wind_Direction_ 

Variability 

The  angular  range  of  the 
Wind_Direction  during  a  relatively 
short  reporting  period. 

EDCS 

Wind_Gale_Force_Rate_ 

Climatology 

The  fraction  of  historical 

(climatology)  gale  force 

Wind_Speeds  (greater  than  or 
equal  to  17.49  m/s). 

EDCS 

Wind_Gust_Speed 

The  speed  of  a  sudden,  brief 
increase  in  Wind_Speed. 

EDCS,  JMCDM 

Wind_Gust_Spread 

The  difference  between  adjacent 
peaks  and  lulls  in  Wind_Speed. 

EDCS,  JMCDM 

Wind_Speed 

Ratio  of  distance  covered  by  air  to 

the  time  taken  to  cover  it. 

EDCS,  JMCDM 

Wind_Speed_20_ 

Percentile_Climatology 

The  minimum  Wind_Speed  that  is 
greater  than  20  percent  of  the 
Wind_Speed_Climatology. 

EDCS,  JMCDM 

Wind_Speed_50_ 

Percentile_Climatology 

The  minimum  Wind_Speed  that  is 
greater  than  50  percent  of  the 
Wind_Speed_Climatology. 

EDCS,  JMCDM 

Wind_Speed_80_ 

Percentile_Climatology 

The  minimum  Wind_Speed  that  is 
greater  than  80  percent  of  the 
Wind_Speed_Climatology. 

EDCS,  JMCDM 
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Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

Wind_Speed_Climatology 

The  mean  historical  (climatology) 
Wind_Speed. 

EDCS,  JMCDM 

Wind_Speed_Climatology 

_Std_Dev 

The  standard  deviation  of 

Wind_Speed_Climatology 

measurements. 

EDCS 

Wind_Speed_East 

The  Wind_Speed  in  the  east-west 
direction,  where  east  is  positive. 

EDCS 

Wind_Speed_East_ 

Climatology 

The  mean  historical  (climatology) 
Wind_Speed_East. 

EDCS,  JMCDM 

Wind_Speed_East_ 

Clim_Std_Dev 

The  standard  deviation  of  the 

Wind_Speed_East_Climatology. 

EDCS 

Wind_Speed_North 

The  Wind_Speed  in  the  north- 
south  direction,  where  north  is 

positive. 

EDCS 

Wind_Speed_North_ 

Climatology 

The  mean  historical  (climatology) 
Wind_Speed_North. 

EDCS,  JMCDM 

Wind_Speed_North_ 

Clim_Std_Dev 

The  standard  deviation  of  the 

Wind_Speed_North_Climatology. 

EDCS 

Wind_Speed_East 

The  Wind_Speed  in  the  east-west 
direction,  where  east  is  positive. 

EDCS 

Wind_Speed_East_ 

Climatology 

The  mean  historical  (climatology) 
Wind_Speed_East. 

EDCS 

Wind_Speed_East_Clim_ 

Std_Dev 

The  standard  deviation  of  the 

Wind_Speed_East_Climatology. 

EDCS 

Wind_Speed_Octant_ 

Fraction 

A  number  between  0  and  1 
inclusive  representing  the  linearly 

scaled  fraction  of  observations 
reporting  Wind_Speeds  within  a 
cardinal  vector  octant  (a  45  arc 
degree  sector  centered  on  a 
cardinal  direction). 

EDCS,  JMCDM 

Wind_Speed_U 

The  component  of  Wind_Speed  in 
the  x  direction  of  a  projected 
coordinate  system. 

EDCS 

Wind_Speed_V 

The  component  of  Wind_Speed  in 
the  y  direction  of  a  projected 
coordinate  system. 

EDCS 

Wind_Speed_W 

The  component  of  Wind_Speed  in 
the  z  direction  of  a  projected 
coordinate  system. 

EDCS 

Wind_Type 

Type  of  a  wind. 

1 

calm 

Wind  speeds  less  than 

9.260  kph. 

EDCS,  JMCDM 

2 

normal 

Normal 

EDCS,  JMCDM 
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Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

3 

squall 

Strong  wind  characterized 
by  a  sudden  onset  in  which 
the  Wind_Speed  increases 
at  least  29.632  km  (16 
nautical  miles)  per  hour 

and  is  sustained  at  40.744 
km  (22  nautical  miles)  per 

hour  or  more  for  at  least  1 

minute. 

EDCS,  JMCDM 

4 

variable 

Variable 

EDCS,  JMCDM 

Thunderstorm_Maximum 
_Wind_  Speed 

The  maximum  Wind_Speed 

measured  within  a  thunderstorm. 

EDCS 

Table  C4.  Weather  class:  CLOUD_COVER. 


Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

Below_Station_ 

Cloud_Coverage 

Cloud  coverage  of  the  sky 

below  an  observation  station 

located  in  the  mountains  on 

earth. 

1 

none_present 

EDCS,  JMCDM 

2 

one_okta 

EDCS,  JMCDM 

3 

two_okta 

EDCS,  JMCDM 

4 

three_okta 

EDCS,  JMCDM 

5 

four_okta 

EDCS,  JMCDM 

6 

five_okta 

EDCS,  JMCDM 

7 

six_okta 

EDCS,  JMCDM 

8 

seven_okta 

EDCS,  JMCDM 

9 

eight_okta 

EDCS,  JMCDM 

10 

sky_obscured 

EDCS,  JMCDM 

11 

partial_obscurati 

on 

EDCS,  JMCDM 

12 

scattered 

EDCS,  JMCDM 

13 

broken 

EDCS,  JMCDM 

14 

few 

EDCS,  JMCDM 

15 

indiscernable 

EDCS,  JMCDM 

Below_Station 

_Cloud_Top_Altitude 

The  highest  surface  of  a 
Cloud_Top  or  a  Cloud_Layer 
relative  an  atmospheric 

vertical  reference  below  an 

observation  station  located  in 

the  mountains  on  earth. 

EDCS,  JMCDM 
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Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

Below_Station 

_Cloud_Top_ 

Characteristics 

The  characteristics  of  the 
Cloud_Top  or  a  Cloud_Layer 

below  an  observation  station 

located  in  the  mountains  on 

earth. 

1 

fragmented 

Isolated  clouds  or 

fragments  of  clouds. 

EDCS,  JMCDM 

2 

cont_flat_tops 

Continuous  clouds  with 

flat  Cloud_Tops. 

EDCS,  JMCDM 

3 

sml_breaks_flat_ 

tops 

Clouds  with  small 

breaks  and  flat 

Cloud_Tops. 

EDCS,  JMCDM 

4 

lrg_breaks_flat 

_tops 

Clouds  with  small 

breaks  and  flat 

Cloud_Tops. 

EDCS,  JMCDM 

5 

cont_undulating_ 

tops 

Continuous  clouds  with 

undulating  Cloud_Top. 

EDCS,  JMCDM 

6 

lrg_breaks_undu- 

lating_tops 

Clouds  with  large 
breaks  and  undulating 
Cloud_Tops. 

EDCS,  JMCDM 

7 

sml_breaks_un- 

dulating_tops 

Clouds  with  small 

breaks  and  undulating 
Cloud_Tops. 

EDCS,  JMCDM 

8 

cont_towering_ 

tops 

Continuous  or  almost 

continous  clouds  with 

towering  Cloud_Tops 
above  the  Cloud_Layer. 

EDCS,  JMCDM 

9 

wave_groups_ 

with_towering 

Groups  of  waves  of 
clouds  with  towering 
Cloud_Tops  above  the 
Cloud_Layer. 

EDCS,  JMCDM 

10 

multiple_layers_ 
and  Jevels 

Two  or  more 

Cloud_Layers  at 

different  levels. 

EDCS,  JMCDM 

11 

cloud_not_visible 

Clouds  are  not  visible 

due  to  darkness  and  or 

fog,  blowing  dust, 
blowing  sand  or  other 
obscuring  phenomena. 

EDCS,  JMCDM 

Below_Station_ 

Cloud_Type 

1 

cirrus 

Detached  clouds  in  a 

form  of  white  delicate 
filaments  and/or  white 
or  mostly  white  patches 

or  narrow  bands. 

EDCS,  JMCDM 
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Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

2 

cirrocumulus 

A  thin  and  white  patch, 
sheet  and/or 

Cloud_Layer  without 
shading  that  is 
composed  of  very  small 

elements  in  the  form  of 

grains  and/or  ripples 
that  are  merged  or 
separated  and  more  or 
less  regularly  arranged. 

EDCS,  JMCDM 

3 

cirrostratus 

A  transparent,  whitish 

veil  of  clouds  of  fibrous 

or  smooth  appearance 
that  totally  or  partially 
covers  the  sky  and 
generally  produces  halo 
phenomena. 

EDCS,  JMCDM 

4 

altocumulus 

A  white  or  grey  or  both 
white  and  grey  patch, 
sheet,  and/or 
Cloud_Layer,  generally 
with  shading, 
composed  of  laminae, 
rounded  masses,  or 

rolls,  which  are  fibrous 

or  diffuse  and  which 

may  or  may  not  be 
merged.  Most  of  the 
regularly  arranged, 
small  elements  usually 
have  an  apparent  width 

between  1  and  5  arc 

degrees  as  observed 

from  the  earth. 

EDCS,  JMCDM 

5 

altostratus 

A  gray  and/or  bluish 
cloud  sheet  and/or 
Cloud_Layer  of  striated, 
fibrous,  or  uniform 
appearance  that  totally 
or  partially  covers  the 
sky  and  has  parts  thin 
enough  to  reveal  the 
sun  at  least  vaguely,  as 
through  ground  glass, 

and  does  not  show  halo 

phenomena 

EDCS,  JMCDM 
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Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

6 

nimbostratus 

A  grey  Cloud_Layer  that 
is  often  dark  with  an 

appearance  rendered 
diffuse  by  more  or  less 
continuously  falling  rain 
and/or  snow,  which  in 

most  cases  reaches  the 

earth,  and  thick  enough 
throughout  to  blot  out 

the  sun. 

EDCS,  JMCDM 

7 

stratocumulus 

A  grey  or  whitish  or  both 
grey  and  whitish  patch, 
sheet,  and/or 
Cloud_Layer  that 
almost  always  has  dark 
parts  composed  of 
tessellations,  rounded 

masses,  or  rolls,  that 
are  non-fibrous  (except 
for  virga)  and  which 
may  or  may  not  be 
merged.  Most  of  the 
regularly  arranged, 

small  elements  have  an 

apparent  width  of  more 
than  5  arc  degrees  as 

observed  from  the 

earth. 

EDCS,  JMCDM 

8 

stratus 

A  generally  grey 
Cloud_Layer  with  a 
fairly  uniform  base  that 
may  give  drizzle,  ice 
prisms,  or  snow  grains. 

When  the  sun  is  visible 

through  the 

Cloud_Layer,  its  outline 
is  clearly  discernible 

and  does  not  show  halo 

phenomena  except 
possibly  at  very  low 
AIR_TEMPERATUREs. 

EDCS,  JMCDM 
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Source 

Name 

Definition 

Value 

Label 

Definition 

9 

cumulus 

Detached  clouds  that 

are  generally  dense 
with  sharp  outlines  and 
develop  vertically  in  the 
form  of  rising  mounds, 
domes,  and/or  towers, 
the  bulging  upper  part 

of  which  often 

resembles  a 

cauliflower.  The  sunlit 

parts  of  these  clouds 
are  mostly  brilliant 

white  and  the  bases  are 

relatively  dark  and 
nearly  horizontal. 

EDCS,  JMCDM 

10 

cumulonimbus 

A  heavy  and  dense 

cloud  with  considerable 

vertical  extent  in  the 

form  of  a  mountain  or  a 

set  of  huge  towers.  At 
least  part  of  its  upper 
portion  is  usually 
smooth,  fibrous,  or 
striated,  and  nearly 
always  flattened.  This 
portion  often  spreads 
out  in  the  shape  of  an 
anvil  or  vast  plume. 

EDCS,  JMCDM 

11 

not_visible 

Clouds  are  not  visible 

due  to  darkness  and  or 

fog,  blowing  dust, 
blowing  sand  or  other 
obscuring  phenomena. 

EDCS,  JMCDM 

12 

no_clouds 

No  clouds  are  present. 

EDCS,  JMCDM 

Cloud_Base 

The  lowest  level  in  a  specific 
cloud  or  Cloud_Layer  where 
the  atmosphere  contains  a 
perceptible  quantity  of 
particles  of  the  cloud. 

EDCS 

Cloud_Base_Level 

The  vertical  displacement  of 
a  Cloud_Base  from  a  surface 
datum  identified  by  an 
atmospheric  vertical 

reference. 

EDCS,  JMCDM 

Cloud_Ceiling_Altitude 

The  altitude  of  the  lowest 

cloud.  The  altitude  is  AGL 
below  3,048  m  (10,000  feet), 

and  then  becomes  MSL  at 

and  above  3,048  m  (10,000 
feet). 

EDCS,  JMCDM 
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Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

Cloud_Layer 

An  arrangement  of  clouds, 
continuous  or  composed  of 
separated  components, 

where  the 

Cloud_Base_Levels  are  the 

same  and  the 

Cloud_Thicknesses  are 
approximately  the  same. 

EDCS 

Cloud_Liquid_ 

Water_Content 

The  liquid  water  content  of  a 

unit  volume  of  cloud. 

EDCS 

Cloud_Phase 

The  phase  (liquid/solid 
disposition)  of  the  water 

content  of  a  cloud. 

1 

liquid 

Composed  of  liquid 
(non-frozen)  water. 

EDCS 

2 

mixed 

Mixed  liquid  and  solid. 

EDCS 

3 

solid 

Composed  of  frozen 

water. 

EDCS 

Cloud_Sky_Cover_Layer_ 

Type 

The  type  of  cloud  that 
comprises  a  sky  cover  layer. 

1 

cirrus 

Detached  clouds  in  a 

form  of  white  delicate 
filaments  and/or  white 
or  mostly  white  patches 

or  narrow  bands. 

EDCS,  IMETS, 

JMCDM 

2 

cirrocumulus 

A  thin  and  white  patch, 
sheet  and/or 

Cloud_Layer  without 
shading  that  is 
composed  of  very  small 

elements  in  the  form  of 

grains  and/or  ripples 
that  are  merged  or 
separated  and  more  or 
less  regularly  arranged. 

EDCS,  IMETS, 

JMCDM 

3 

cirrostratus 

A  transparent,  whitish 

veil  of  clouds  of  fibrous 

or  smooth  appearance 
that  totally  or  partially 
covers  the  sky  and 
generally  produces  halo 
phenomena. 

EDCS,  IMETS, 

JMCDM 
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4 

altocumulus 

A  white  or  grey  or  both 
white  and  grey  patch, 
sheet,  and/or 
Cloud_Layer,  generally 
with  shading, 
composed  of  laminae, 
rounded  masses,  or 

rolls,  which  are  fibrous 

or  diffuse  and  which 

may  or  may  not  be 
merged.  Most  of  the 
regularly  arranged, 
small  elements  usually 
have  an  apparent  width 

between  1  and  5  arc 

degrees  as  observed 

from  the  earth. 

EDCS,  IMETS, 

JMCDM 

5 

altostratus 

A  gray  and/or  bluish 
cloud  sheet  and/or 
Cloud_Layer  of  striated, 
fibrous,  or  uniform 
appearance  that  totally 
or  partially  covers  the 
sky  and  has  parts  thin 
enough  to  reveal  the 
sun  at  least  vaguely,  as 
through  ground  glass, 

and  does  not  show  halo 

phenomena 

EDCS,  IMETS, 

JMCDM 

6 

nimbostratus 

A  grey  Cloud_Layer  that 

is  often  dark  with  an 

appearance  rendered 
diffuse  by  more  or  less 
continuously  falling  rain 
and/or  snow,  which  in 

most  cases  reaches  the 

earth,  and  thick  enough 
throughout  to  blot  out 

the  sun. 

EDCS,  IMETS, 

JMCDM 
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Enumeration 
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Name 

Definition 

Value 

Label 

Definition 

7 

stratocumulus 

A  grey  or  whitish  or  both 
grey  and  whitish  patch, 
sheet,  and/or 
Cloud_Layer  that 
almost  always  has  dark 
parts  composed  of 
tessellations,  rounded 

masses,  or  rolls,  that 
are  non-fibrous  (except 
for  virga)  and  which 
may  or  may  not  be 
merged.  Most  of  the 
regularly  arranged, 

small  elements  have  an 

apparent  width  of  more 
than  5  arc  degrees  as 

observed  from  the 

earth. 

EDCS,  IMETS, 

JMCDM 

8 

stratus 

A  generally  grey 
Cloud_Layer  with  a 
fairly  uniform  base  that 
may  give  drizzle,  ice 
prisms,  or  snow  grains. 

When  the  sun  is  visible 

through  the 

Cloud_Layer,  its  outline 
is  clearly  discernible 

and  does  not  show  halo 

phenomena  except 
possibly  at  very  low 
AIR_TEMPERATUREs. 

EDCS,  IMETS, 

JMCDM 

9 

cumulus 

Detached  clouds  that 

are  generally  dense 
with  sharp  outlines  and 
develop  vertically  in  the 
form  of  rising  mounds, 
domes,  and/or  towers, 
the  bulging  upper  part 

of  which  often 

resembles  a 

cauliflower.  The  sunlit 

parts  of  these  clouds 
are  mostly  brilliant 

white  and  the  bases  are 

relatively  dark  and 
nearly  horizontal. 

EDCS,  IMETS, 

JMCDM 

160 


ERDC  TR-07-4 


Attribute 

Enumeration 
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10 

cumulonimbus 

A  heavy  and  dense 

cloud  with  considerable 

vertical  extent  in  the 

form  of  a  mountain  or  a 

set  of  huge  towers.  At 
least  part  of  its  upper 
portion  is  usually 
smooth,  fibrous,  or 
striated,  and  nearly 
always  flattened.  This 
portion  often  spreads 
out  in  the  shape  of  an 
anvil  or  vast  plume. 

EDCS,  IMETS, 

JMCDM 

11 

not_visible 

Clouds  are  not  visible 

due  to  darkness  and  or 

fog,  blowing  dust, 
blowing  sand  or  other 
obscuring  phenomena. 

EDCS,  IMETS, 

JMCDM 

Cloud_Thickness 

The  vertical  distance 

between  the  Cloud_Base  and 
the  Cloud_Top. 

EDCS 

Cloud_Top 

The  highest  level  in  a  specific 
cloud  or  Cloud_Layer  where 
the  atmosphere  contains  a 
perceptible  quantity  of 
particles  of  the  cloud. 

EDCS 

Cloud_Top_Level 

The  vertical  displacement  of 
a  Cloud_Top  from  a  surface 
datum  identified  by  an 
atmospheric  vertical 

reference. 

EDCS 

Convective_Cloud_Layer 

A  number  between  0  and  1 

inclusive  represents  the 
linearly-scaled  fraction  of  the 
sky  that  is  covered  by 
convective  (cumuliform) 
clouds. 

EDCS 

High_Cloud 

A  cloud  of  the  genus  cirrus, 
cirrocumulus,  or  cirrostratus. 
Also  the  top  of  a  cloud  of  the 
genus  cumulonimbus  or, 
occasionally,  altostratus. 

EDCS 

High_Cloud_Base_Level 

The  Cloud_Base_Level  of  a 
High_Cloud. 

EDCS 

High_Cloud_Coverage 

The  fraction  of  the  sky 
covered  by  High_Clouds. 

EDCS,  IMET 
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Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

High_Cloud_Genus 

1 

cirrocumulus 

A  thin  and  white  patch, 
sheet  and/or 

Cloud_Layer  without 
shading  that  is 
composed  of  very  small 

elements  in  the  form  of 

grains  and/or  ripples 
that  are  merged  or 
separated  and  more  or 
less  regularly  arranged. 

EDCS,  IMETS, 

JMCDM 

2 

cirrostratus 

A  transparent,  whitish 

veil  of  clouds  of  fibrous 

or  smooth  appearance 
that  totally  or  partially 
covers  the  sky  and 
generally  produces  halo 
phenomena. 

EDCS,  IMETS, 

JMCDM 

3 

cirrus 

Detached  clouds  in  a 

form  of  white  delicate 

filaments  and/or  white 
or  mostly  white  patches 

or  narrow  bands. 

EDCS,  IMETS, 

JMCDM 

4 

none_present 

No  High_Clouds 
present. 

EDCS,  IMETS, 

JMCDM 

High_Cloud_Top_Level 

The  Cloud_Top_Level  of  a 
High_Cloud. 

EDCS 

Historical 

_Cloud_Free_Line_Of_ 

Sight_Climatology 

The  historical  (climatology) 
probability  of  a  line  of  sight 

free  of  clouds. 

EDCS 

Low_Cloud 

A  cloud  of  the  genus 

stratocumulus  or  stratus. 

Also  the  base  of  a  cloud  of 

the  genus  cumulus. 

EDCS 

Lowest 

_Cloud_Base_Level 

The  Cloud_Base_Level  of  the 

lowest  cloud. 

EDCS,  IMETS, 

JMCDM 

Low_Cloud_Coverage 

The  fraction  of  sky  covered  by 
Low_Clouds. 

EDCS,  IMETS 

Low_Cloud_Genus 

1 

cumulonimbus 

A  heavy  and  dense 

cloud  with  considerable 

vertical  extent  in  the 

form  of  a  mountain  or  a 

set  of  huge  towers.  At 
least  part  of  its  upper 
portion  is  usually 
smooth,  fibrous,  or 
striated,  and  nearly 
always  flattened.  This 
portion  often  spreads 
out  in  the  shape  of  an 
anvil  or  vast  plume. 

EDCS,  IMETS, 

JMCDM 
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2 

cumulus 

Detached  clouds  that 

are  generally  dense 
with  sharp  outlines  and 
develop  vertically  in  the 
form  of  rising  mounds, 
domes,  and/or  towers, 
the  bulging  upper  part 

of  which  often 

resembles  a 

cauliflower.  The  sunlit 

parts  of  these  clouds 
are  mostly  brilliant 

white  and  the  bases  are 

relatively  dark  and 
nearly  horizontal. 

EDCS,  IMETS, 

JMCDM 

3 

none_present 

No  Low_Clouds  are 
present. 

EDCS,  IMETS, 

JMCDM 

4 

stratocumulus 

A  grey  or  whitish  or  both 
grey  and  whitish  patch, 
sheet,  and/or 
Cloud_Layer  that 
almost  always  has  dark 
parts  composed  of 
tessellations,  rounded 

masses,  or  rolls,  that 
are  non-fibrous  (except 
for  virga)  and  which 
may  or  may  not  be 
merged.  Most  of  the 
regularly  arranged, 

small  elements  have  an 

apparent  width  of  more 
than  5  arc  degrees  as 
observed  from  the 

earth. 

EDCS,  IMETS, 

JMCDM 

5 

stratus 

A  generally  grey 
Cloud_Layer  with  a 
fairly  uniform  base  that 
may  give  drizzle,  ice 
prisms,  or  snow  grains. 

When  the  sun  is  visible 

through  the 

Cloud_Layer,  its  outline 
is  clearly  discernible 

and  does  not  show  halo 

phenomena  except 
possibly  at  very  low 
AIR_TEMPERATUREs. 

EDCS,  IMETS, 

JMCDM 

Low_Cloud_Top_Level 

The  Cloud_Top_Level  of  a 
Low_Cloud. 

EDCS,  JMCDM 

Lowest 

_Cloud_Base_Level 

The  Cloud_Base_Level  of  the 

lowest  cloud. 

EDCS,  JMCDM 
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Lowest_Cloud_ 

Cover_Category 

A  category  indicating  the 
fraction  of  the  sky  covered  by 
Low_Clouds,  if  no 

Low_Clouds  are  present,  the 
fraction  of  sky  covered  by  the 
Middle_Clouds. 

1 

none_present 

EDCS,  IMETS, 

JMCDM 

2 

one_okta 

EDCS,  IMETS, 

JMCDM 

3 

two_okta 

EDCS,  IMETS, 

JMCDM 

4 

three_okta 

EDCS,  IMETS, 

JMCDM 

5 

four_okta 

EDCS,  IMETS, 

JMCDM 

6 

five_okta 

EDCS,  IMETS, 

JMCDM 

7 

six_okta 

EDCS,  IMETS, 

JMCDM 

8 

seven_okta 

EDCS,  IMETS, 

JMCDM 

9 

eight_okta 

EDCS,  IMETS, 

JMCDM 

10 

partial_obscurati 

on 

EDCS,  IMETS, 

JMCDM 

11 

sky_obscured 

EDCS,  IMETS, 

JMCDM 

Middle_Cloud 

A  cloud  of  the  genus 
altocumulus,  altostratus,  or 
nimbostratus.  Also  portions 
of  a  cloud  of  the  genus 

cumulus  or  cumulonimbus. 

Middle_Cloud 

_Base_Level 

The  Cloud_Base_Level  of  a 
Middle_Cloud. 

Middle_Cloud_Coverage 

The  fraction  of  the  sky 
covered  by  Middle_Clouds. 
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Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

Middle_Cloud_Genus 

1 

altocumulus 

A  white  or  grey  or  both 
white  and  grey  patch, 
sheet,  and/or 
Cloud_Layer,  generally 
with  shading, 
composed  of  laminae, 
rounded  masses,  or 

rolls,  which  are  fibrous 

or  diffuse  and  which 

may  or  may  not  be 
merged.  Most  of  the 
regularly  arranged, 
small  elements  usually 
have  an  apparent  width 

between  1  and  5  arc 

degrees  as  observed 

from  the  earth. 

EDCS,  IMETS, 

JMCDM 

2 

altostratus 

A  gray  and/or  bluish 
cloud  sheet  and/or 
Cloud_Layer  of  striated, 
fibrous,  or  uniform 
appearance  that  totally 
or  partially  covers  the 
sky  and  has  parts  thin 
enough  to  reveal  the 
sun  at  least  vaguely,  as 
through  ground  glass, 

and  does  not  show  halo 

phenomena. 

EDCS,  IMETS, 

JMCDM 

3 

nimbostratus 

A  grey  Cloud_Layer  that 

is  often  dark  with  an 

appearance  rendered 
diffuse  by  more  or  less 
continuously  falling  rain 
and/or  snow,  which  in 

most  cases  reaches  the 

earth,  and  thick  enough 
throughout  to  blot  out 

the  sun. 

EDCS,  IMETS, 

JMCDM 

4 

none_present 

No  Middle_Clouds 
present. 

EDCS,  IMETS, 

JMCDM 

Middle_Cloud_Top_Level 

The  Cloud_Top_Level  of  a 
Middle_Cloud. 

EDCS 

Total_Cloud_Coverage 

The  fraction  of  the  sky  hidden 
by  all  clouds. 

EDCS,  JMCDM 

Total_Cloud 

_Coverage_Category 

A  category  describing  the 
Total_Cloud_Coverage. 

1 

none_present 

EDCS,  IMETS, 

JMCDM 

2 

one_okta 

EDCS,  IMETS, 

JMCDM 

3 

two_okta 

EDCS,  IMETS, 

JMCDM 
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Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

4 

three_okta 

EDCS,  IMETS, 

JMCDM 

5 

four_okta 

EDCS,  IMETS, 

JMCDM 

6 

five_okta 

EDCS,  IMETS, 

JMCDM 

7 

six_okta 

EDCS,  IMETS, 

JMCDM 

8 

seven_okta 

EDCS,  IMETS, 

JMCDM 

9 

eight_okta 

EDCS,  IMETS, 

JMCDM 

10 

sky_obscured 

EDCS,  IMETS, 

JMCDM 

11 

partial_obscurati 

on 

EDCS,  IMETS, 

JMCDM 

12 

scattered 

EDCS,  IMETS, 

JMCDM 

13 

broken 

EDCS,  IMETS, 

JMCDM 

14 

few 

EDCS,  IMETS, 

JMCDM 

15 

indiscernable 

EDCS,  IMETS, 

JMCDM 

Table  C5.  Weather  class:  LIGHTING_AND_VISIBILITY. 


Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

Blackout_Brake_ 

Lightjntensity 

A  number  between  0  and  1 

inclusive  represents  the 
linearly  scaled  fractional 
intensity  of  external  lighting 
that  is  designed  for  use 
under  military  blackout 
conditions  to  prevent 
collision  with/between 

vehicles. 

EDCS 

Blackout_Light_lntensity 

A  number  between  0  and  1 

inclusive  represents  the 
linearly  scaled  fractional 
intensity  of  internal  lighting 
that  is  designed  for  use 
under  military  blackout 

conditions. 

EDCS 
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Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

Bmnt 

Begin  Morning  Nautical 

Twilight.  The  start  of  that 
period  where,  in  good 

conditions  and  in  the 

absence  of  other 

illumination,  enough  light  is 
available  to  identify  the 
general  outlines  of  ground 
objects  and  conduct  limited 
military  operations.  Light 

intensification  devices  are 

still  effective  and  may  have 
enhanced  capabilities.  At  this 
time,  the  sun  is  12  degrees 

below  the  eastern  horizon. 

JP  1-02  DOD 

Dictionary  of 
Military  Terms 

Ceiling_And_Visibility_Ok 

An  indication  that  CAVOK 

conditions  prevail. 

0 

false 

1 

true 

(1)  VISIBILITY  is  10  km 
or  more;  (2)  there  are 

no  CLOUDs  below  1.5 

km  or  below  the  highest 

minimum  sector 

altitude,  whichever  is 
greater;  and  (3)  there 

are  no  cumulonimbus 

CLOUDs, 

PRECIPITATION, 
thunderstorms,  shallow 
fog,  or  low  drifting  snow 
ground  cover  present. 

EDCS 

Cloud_Free_ 

Line_Of_Sight 

The  fraction  of  all  lines  of 

sight  that  are  unhampered  by 

clouds. 

EDCS 

Eent 

End  of  Evening  Nautical 
Twilight.  It  is  the  time  when 
the  sun  has  set  but  enough 
light  is  still  available  to 
identify  the  general  outlines 
of  ground  objects  and 
conduct  limited  military 
operations.  Light 

intensification  devices  are 
still  effective  and  may  have 
enhanced  capabilities.  At  this 
time,  the  sun  is  12  degrees 

below  the  western  horizon. 

Inferred  from 

JP  1-02  DOD 

Dictionary  of 
Military  Terms 

Fog_Coverage_Fraction 

A  number  between  0  and  1 

inclusive  represents  the 
linearly-scaled  fractional  area 
of  a  region  of  a  planetary 
surface  that  is  covered  by 
fog,  as  seen  from  above. 

0 

no_coverage 

EDCS 
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Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

1 

complete 

_coverage 

EDCS 

Fog_Detector_ 

Light_Present 

An  indication  that  an  object 

has  an  associated  detector 

light  for  fog. 

EDCS 

Fog_Extinction 

Coefficient 

The  extinction  coefficient  due 

to  fog. 

EDCS 

Fog_Present 

An  indication  that  fog  is 
present. 

EDCS 

Fog_Probability 

The  probability  of  the 
occurrence  of  fog. 

EDCS 

Fog_Proba  bi  1  ity_Rate 

Estimated  rate  of 

fog_probability. 

JMCDM 

Fog_Region 

A  region  of  fog  at  or  near  a 
planetary  surface. 

EDCS 

Fog_Thickness 

The  height  of  a  bank  of  fog 

relative  to  the  local  terrain 

where  the  base  of  the  fog  is 
assumed  to  be  at  ground 

level. 

EDCS 

Geographic_Light_Range 

The  maximum  distance  at 

which  the  curvature  of  the 

earth  and  refraction  due  to 

the  ATMOSPHERE  permit  a 
light  to  be  seen  from  a 
particular  height  of  eye 
without  regard  to  the 
luminous  intensity  of  the 
light. 

EDCS 

Light_Elevation 

The  elevation  of  a  light. 

EDCS 

Light_Exhibition 

Condition 

The  condition  of  a  light. 

1 

constant 

EDCS 

2 

daytime 

EDCS 

3 

night_time 

EDCS 

4 

reduced_visibility 

EDCS 

Light_Function 

The  function  of  a  light. 

18 

enume 

rations 

EDCS 

Light_Multiplicity 

The  number  of  lights  of  the 

same  kind  at  a  location. 

EDCS 

Light_Pattern 

The  type  of  sequence, 
grouping,  and/or  distinctive 
character  of  a  light. 

41 

enume 

rations 

EDCS 

Light_Period 

The  Time_Quantity  occupied 
by  an  entire  cycle  of  intervals 
of  light  and  dark  of  a  light. 

EDCS 
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Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

Light_Relative_Location 

The  relative  horizontal 

location  of  a  light  in  a  range 
of  two  or  three  lights. 

4 

enume 

rations 

EDCS 

Light_Sector_Angle 

The  horizontal  angular  sector 
limts  of  the  visibility  of  a  light. 

EDCS 

Light_Type 

The  type  of  light. 

1 

display 

EDCS 

2 

spotlight 

EDCS 

3 

streetjight 

EDCS 

Light_Visibility 

The  type  of  specific  visibility 
of  a  light,  with  respect  to  the 
intensity  of  the  light  and  ease 
of  recognition. 

1 

deliberately_restr 

icted 

EDCS 

2 

faint 

EDCS 

3 

highjntensity 

EDCS 

4 

intensified 

EDCS 

5 

lowjntensity 

EDCS 

6 

obscured 

EDCS 

7 

partially_obscure 

d 

EDCS 

8 

unintensified 

EDCS 

Low_Visibility_Ranges 

A  set  of  two  numbers 

defining  the  range  of  visibility 
at  a  light  in  nautical  miles. 

EDCS 

Low_Visibility_Region 

An  ATMOSPHERE  region  of 
reduced  visibility  near  a 
planetary  surface. 

EDCS 

Lighting_Characterization 

The  qualitative 
characterization  of  lighting 
intensity. 

1 

brightlyjit 

EDCS 

2 

dimlyjit 

EDCS 

3 

lights_off 

EDCS 

Luminous_Light_Range 

The  maximum  distance  at 

which  a  light  can  be  seen 
under  existing  visibility 
conditions  taking  no  account 
of  the  height  of  the  light,  the 
height  of  the  observer,  or 

interference  from 

background  lighting. 

EDCS 

Maximum_Visibility_Rang 

e 

The  maximum  range  of 
visibility  into  an  object  (i.e.,  a 
forest). 

EDCS 

Mean_Visibility_Distance 

Mean_Visibility_Distance 

derived  from  successive 

visibility  measurements. 

JMCDM 
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Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

Meteorological_Range 

The  distance  at  which  an 

ideal  observer  can  detect  a 

high-contrast  target 
assuming  a  detection 

contrast  threshold  of  0.02 

and  a  target  inherent 

contrast  of  1.0. 

EDCS 

Moon_Phase 

The  phase  of  the  moon. 

1 

new_moon 

EDCS 

2 

waxing_crescent 

EDCS 

3 

first_quarter 

EDCS 

4 

waxing_gibbous 

EDCS 

5 

full_moon 

EDCS 

6 

waning_gibbous 

EDCS 

7 

last_quarter 

EDCS 

8 

waning_crescent 

EDCS 

Moon_Phase_Time 

The  time  at  which  a 

Moon_Phase  occurs. 

EDCS 

Moonrise_Time 

The  time  of  day  of  moonrise. 

EDCS 

Moonset_Time 

The  time  of  day  of  moonset. 

EDCS 

Nominal_Light_Range 

The  maximum  distance  at 

which  a  light  can  be  seen  in 
clear  weather  as  defined  by 
the  International  Visibility 

Code. 

Obscurant_Type 

The  type  of  obscurant 
present  in  an  atmosphere. 

1 

advection_fog 

Fog  caused  by 

advection  of  most  air 

over  a  cold  surface. 

EDM-AOS, 

EDCS 

2 

blowing_snow 

Snow  lifted  over  the 

surface  by  wind  to  a 
height  of  2  m  or  more. 

EDM-AOS, 

EDCS 

3 

desert_haze 

EDM-AOS, 

EDCS 

6 

duststorm 

Strong  wind  and  dust 
suspension  over  an 
extensive  region. 

EDM-AOS, 

EDCS 

7 

haze 

Suspension  in  the 
atmosphere  of 
extremely  small,  dry 
particles  that  are 

invisible  to  the  naked 

eye  but  numerous 
enough  to  give  the  sky 
an  opalescent 

appearance. 

EDM-AOS, 

EDCS 

9 

none_present 

EDM-AOS, 

EDCS 
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Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

10 

radiation_fog 

Fog  produced  over  a 

tract  when  radiational 

cooling  reduces  the 
AIR_TEMPERATURE  to 

or  below  its 

DEW_P0INT. 

EDM-AOS, 

EDCS 

11 

rural_haze 

EDM-AOS, 

EDCS 

12 

snow 

Obscuration  caused  by 
the  presence  of  snow 
PRECIPITATION 

suspended  in  the 

ATMOSPHERE. 

EDM-AOS, 

EDCS 

13 

temperate_sum 

mer_day 

Condition  present 
during  the  sumer  and 
dependent  on  the 

AIR_TEMPERATURE 
during  the  day. 

EDM-AOS, 

EDCS 

14 

temperate_ 

summer_night 

Condition  present 
during  the  sumer  and 
dependent  on  the 

AIR_TEMPERATURE 
during  the  night. 

EDM-AOS, 

EDCS 

15 

temperate_winte 

r 

Condition  present 
during  the  winter 
season  and  dependent 

on  the 

AIR_TEMPERATURE  at 

the  time. 

EDM-AOS, 

EDCS 

17 

urban_haze 

Haze  caused  by  or 
present  in  urban 

environment. 

EDM-AOS, 

EDCS 

Observed 

_Visibility_Report_Type 

The  type  of  report  of 
observed  visibility 

1 

minimum 

EDCS 

2 

prvl 

EDCS 

3 

prvl_var_high 

EDCS 

4 

prvl_var_low 

EDCS 

5 

sector 

EDCS 

6 

tower 

EDCS 

7 

tower_var_high 

EDCS 

8 

tower_var_low 

EDCS 
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Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

Opacity 

A  number  between  0  and  1 

representing  a  linearly-scaled 
fraction  specifying  the  degree 
of  light  of  sight  blockage.  The 
value  is,  on  average,  the 

fraction  of  the  cross-sectional 
Area  of  a  non-homogeneous 
object  that  completely  blocks 
the  line  of  sight. 

EDCS 

Periodjnterval 

The  interval  of  time  between 

successive  measurements. 

JMCDM 

Period_Quantity 

The  Time_Quantity  over 
which  visibility 
measurements  are  sampled. 

JMCDM 

Received_Ambient 

_Light_Scaled_lntensity 

A  number  between  0  and  1 

inclusive  representing  the 
linearly  scaled  fractional  light 
intensity  received  by  an 
object  from  all  unlocalized 

sources. 

EDCS 

Road_La  ne_Light_State 

The  state  of  the  traffic  light  at 

the  end  of  a  route  lane. 

7 

enum 

merati 

ons 

EDCS 

Road_Lighting_Present 

An  indication  that  a  road  is 

illuminated  bystreet  lamps. 

EDCS 

Sky_Obscuration 

_Fraction 

The  fraction  of  the  sky  that  is 
covered  by  fog  or  other  low- 
altitude  atmospheric 
phenomena. 

EDCS 

Sunshine_Period 

The  Time_Quantity  that  solar 

irradiation  occurred. 

EDCS 

Sunrise_Time 

The  time  of  day  of  sunrise. 

EDCS 

Sunset_Time 

The  time  of  day  of  sunset. 

EDCS 

Urban_Street_ 

Light_l  intensity 

A  number  between  0  and  1 

inclusive  representing  the 
linearly-scaled  fractional 
intensity  of  the  lighting  on  an 

urban  street.  Zero  means 

unlit  and  one  means 

maximum  intensity. 

EDCS 

Visibility_Bearing 

Direction  a  visibility  is 

observed. 

E 

east 

JMCDM 

N 

north 

JMCDM 

NE 

northeast 

JMCDM 

NW 

northwest 

JMCDM 

S 

south 

JMCDM 

SE 

southeast 

JMCDM 

SW 

southwest 

JMCDM 
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Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

W 

west 

JMCDM 

Visibility_Distance 

The  greatest  distance  in  a 
given  direction  at  which  it  is 
just  possible  to  see  and 
identify  with  the  unaided  eye 
either:  (1)  in  the  daytime,  a 
prominent  dark  object 
against  the  sky  at  the  horizon 
or  (2)  at  night,  a  known, 
preferably  unfocused, 
moderately  intense  light. 

EDCS,  JMCDM 

Table  C6.  Weather  class:  ICING. 


Attribute 

Enumeration 

Source 

Name 

Definition 

Value 

Label 

Definition 

Icingjntensity 

The  code  that  denotes  the 

intensity  of  ICING  on  the 
surface. 

0 

none 

JMCDM 

1 

light 

JMCDM 

2 

moderate 

JMCDM 

3 

severe_or_heavy 

JMCDM 

4 

trace 

JMCDM 

5 

unknown 

JMCDM 

lcing_Type 

The  type  of  ice. 

1 

clearjce 

EDCS 

2 

hard_rime 

EDCS 

3 

hoar_frost 

EDCS 

4 

ice_glaze 

EDCS 

5 

rime 

EDCS 

6 

soft_rime 

EDCS 

Probability_Of_lcing 

The  probability  that  ICING  will 
occur  in  a  designated 
Time_Period. 

IMETS 
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APPENDIX  D:  M-COP  MANEUVER  ANALYSIS 
CATEGORY 


Table  Dl.  Maneuver  Analysis  class:  AREA_OF_OPERATIONS.* 


Attribute  or  Associated  Class 

Definition 

Cardinality 

Data  Type 

Units  of  Measure  /  other  notes 

Name 

Unique  name  identifier  of  this  AO. 

1 

string 

Commander 

Commander  of  highest  echelon  unit 
assigned  this  AO. 

1 

string 

This  can  be  used  for  coordination  purposes. 

Unit 

Highest  echelon  unit  assigned  this 

AO. 

1 

string 

e.g.,  Corps,  Division,  Brigade,  Battalion; 
since  doctrine  is  evolving  with 
transformation  of  the  force,  recommend 
leaving  as  a  string  until  terminology  is 
established.  Should  agree  with  Forces 
category  attribute. 

GEOMETRY 

A  spatial  representation  of  the  class; 

note  this  is  from  a  class  in  the  utilities 

category. 

1 

float 

A  polygon. 

Table  D2.  Maneuver  Analysis  class:  TRAFFICABILITY_SEGMENT  (AO).t 


Attribute  or  Associated  Class 

Definition 

Cardinality 

Data  Type 

Units  of  Measure  /  other  notes 

Name 

Unique  name  identifier  or  number  of 
this  TRAFFICABILITY_SECTOR  within 
the  Area  of  Operations  (AO). 

1 

string 

This  could  also  be  a  numeric  data  type, 
depending  on  the  implemention  within  the 
system. 

A0_Name 

Unique  identifier  of  the  AO  associated 
with  the  TRAFFICABILITY_SECTOR. 

1 

string 

Name  given  the  AO. 

Unit 

Type  of  unit  or  platform  for  which 
trafficability  is  estimated. 

1 

string 

Trafficability  can  vary  by  type  of  unit 
(generally  based  on  equipment). 

Traff  i  ca  b  i  1  ity_Est  i  m  ate 

Trafficability  for  the  given  unit  or 
platform. 

1 

integer 

0  -  unrestricted 

1  -  restricted 

2  -  severely  restricted 

Speed 

Maximum  speed  for  this  unit  in  the 
TRAFFICABILITY_SECTOR. 

1 

float 

kph 

*  AREA_OF_OPERATIONS— (DOD)  An  operational  area  defined  by  the  joint  force  commander  for  land  and  naval  forces.  Areas 
of  operations  do  not  typically  encompass  the  entire  operational  area  of  the  joint  force  commander,  but  should  be  large 
enough  for  component  commanders  to  accomplish  their  missions  and  protect  their  forces.  Also  called  AO.  See  also  area 
of  interest;  area  of  responsibility;  battlespace;  joint  operations  area;  joint  special  operations  area.  See  FM  3-0  (HQDA 
2001a).  (Ref.  FM  1-02.) 

t  TRAFFICABILITYJ3EGMENT  describes  the  trafficability  of  a  portion  of  the  AO. 
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Attribute  or  Associated  Class 

Definition 

Cardinality 

Data  Type 

Units  of  Measure  /  other  notes 

GEOMETRY 

A  spatial  representation  of  the 
TRAFFICABILITY_SECTOR;  note  this  is 
from  a  class  in  the  Utilities  category. 

1 

float 

A  polygon. 

FORCE_DISPOSITION 

Affliation 

The  forces  side  associated  with  the 

trafficability  estimate  in  the 
TRAFFICABILITY_SECTOR, 
F0RCE_DISP0SITI0N  is  a  class  in  the 
Forces  category. 

1 

As  represented  by  Forces  category. 

Table  D3.  Maneuver  Analysis  class:  G ROUN D_AVEN U E_OF_APPROACH  (AA).* 


Attribute  or  Associated  Class 

Definition 

Cardinality 

Data  Type 

Units  of  Measure  /  other  notes 

Name 

Unique  name  identifier  for  this  AA. 

1 

string 

A0_Name 

Name  identifier  for  the  AO  with 

which  this  AA  is  associated. 

1 

string 

Number_Of_AA_Segments 

Total  number  count  of  segments 
composing  the  AA. 

1 

integer 

Number_Of_Mobility_Corridors 

Total  number  count  of  mobility 

corridors  within  the  AA. 

1 

integer 

Force_Size 

Size  of  unit  using  this  AA. 

1 

string 

e.g.,  battalion;  since  doctrine  is 
evolving  with  transformation, 
recommend  leaving  as  a  string  until 
terminology  is  established.  Should 
align  with  a  Forces  category 

attribute. 

General_Direction 

Compass  direction  of  approach 
(start  to  end). 

1 

string 

"ENE'1,  ”NNW",  etc. 

F0RCE_DISP0SITI0N 

Affliation 

Side  associated  with  this  AA; 
FORCE_DISPOSITION  is  a  class  in 
the  Forces  category. 

1 

As  represented  by  Forces  category. 

GEOMETRY 

Spatial  representation  of  the  EA; 

note  this  is  from  a  class  in  the 
Utilities  category. 

1 

float 

A  polygon. 

*  GROUND_AVENUE_OF_APPROACH— "(DOD)  ground  route  of  an  attacking  force  of  a  given  size  leading  to  its  objective  or  to 
key  terrain  in  its  path.  Also  called  AA."  FM  1-02  (HQDA  2003a).  Assumes  an  AA  is  contained  within  a  single 
AREA_0F_0PERATI0NS;  an  AA  is  made  up  of  distinct  segments  described  as  straight  lines  with  segment  width. 
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Table  D4.  Maneuver  Analysis  class:  MOBIUTY_CORRIDOR  (MC).* 


Attribute  or  Associated  Class 

Definition 

Cardinality 

Data 

Type 

Units  of  Measure  /  other  notes 

Name 

A  unique  identifier  for 

this 

MOBILITY_CORRIDOR. 

1 

string 

AA_Name 

The  identifier  for  the 

AVENUE_OF_APPROACH 
(AA)  with  which  this 
MOBILITY_CORRIDOR  is 

associated. 

1 

string 

Force_Size 

The  size  of  force  that 
can  pass  through  the 
MOBILITY_CORRIDOR. 

1 

string 

E.g.,  battalion;  since  doctrine  is  evolving  with 
transformation,  recommend  leaving  as  a  string  until 
terminology  is  established.  Should  align  with  Forces 
category  attributes. 

Restriction 

Identifier  of  the 

restriction  being 
bypassed  in  this 
MOBILITY_CORRIDOR. 

1 

string 

Obstacle  will  have  associated  location  information 

(from  Obstacle  category). 

Characteristic_Width 

Characteristic  width  of 

the 

MOBILITY_CORRIDOR 
as  determined  by  the 

direction  of  travel  of  the 

platform  or  force. 

1 

float 

The  most  limiting  dimension  of  the  MC  given  the 

direction  of  travel. 

Trafficability_Estimate 

Category  of  traffics bility 
for  the  given  unit. 

1 

integer 

0  -  unrestricted 

1  -  restricted 

2  -  severely  restricted 

Reason 

Why  choose  this  route 

around  the  obstacle. 

1 

string 

GEOMETRY 

Spatial  representation 

of  the 

MOBILITY_CORRIDOR; 

note  this  is  from  a  class 
in  the  Utilities  category. 

1 

float 

A  polygon. 

MOBILITY_CORRIDOR-"(DOD)  Areas  where  a  force  will  be  canalized  due  to  terrain  restrictions.  They  allow  military  forces 
to  capitalize  on  the  principles  of  mass  and  speed  and  are  therefore  relatively  free  of  obstacles."  (FM  1-02;  HQDA  2003a.) 
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Table  D5.  Maneuver  Analysis  class:  AVENUE_OF_APPROACH_CHANNELIZER.* 


Attribute  or  Associated  Class 

Definition 

Cardinality 

Data  Type 

Units  of  Measure  /  other  notes 

Name 

Unique  name  identifier  for  obstacle  or 

area  that  channelizes  movement 

within  the  AA. 

1 

string 

AA_Name 

Unique  name  identifier  for  AA  with 
which  the  channelizer  (object)  is 

associated. 

1 

string 

Type 

Obstacle  category.  An  obstacle  could 
be  a  minefield  whereas  a  severly 

restricted  area  could  be  a  river  or  a 

marsh.  Obstacles  come  from  the 

Obstacle  categoy  and  have 
associated  geometries  and 

characteristics. 

1 

integer 

0  =  severly  restricted  area 

1  =  restricted  area 

2  =  obstacle 

AA_Segment_ 

Mobility_Corridor_l 

First  corridor  around  the  obstacle. 

1 

string 

Unique  MC  identifier;  should  correspond  to  a 
particular  MOBIUTY_CORRIDOR_NAME  in 
MOESILITY_CORRIDOR  (MC)  subclass. 

AA_Segment_ 

Mobility_Corridor_2 

Second  corridor  around  the  obstacle, 

if  it  exists. 

1 

string 

Null  if  no  second  MC. 

GEOMETRY 

A  spatial  representation  of  the 
obstacle;  note  this  is  from  a  class  in 
the  Utilities  category. 

1 

float 

A  polygon. 

*  AVENUE_OF_APPROACH_CHANNELIZER— Point  or  areal  terrain  feature  of  the  AA  that  will  cause  channelization.  This 
could  be  a  severly  restricted  area,  a  forest,  a  river,  etc. 
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Table  D6.  Maneuver  Analysis  class:  AVENUE_OF_APPROACH_SEGMENT.‘ 


Attribute  or  Associated  Class 

Definition 

Cardinality 

Data 

Type 

Units  of  Measure  /  other  notes 

AA_Name 

Unique  name  identifier  for  AA  of  which 
this  segment  is  a  part. 

1 

string 

Segment_Number 

The  unique  identifier  for  this  segment 

of  the  AA. 

1 

integer 

0  =  start  and  is  associated  with  the  segment 
at  the  start  point  of  the  AA,  increment  by  1 

Segement_Width 

Characteristic  width  of  AA  segment 
perpendicular  to  the  intended 

direction  of  travel. 

1 

float 

meters 

Segment_Visual_Obstructio 

n 

Degree  of  visual  obstruction  in  this 
segment. 

1 

float 

0..1  where  0  -  0%  visibility  and  1  =  100% 
visibility  (100  meters  or  more);  could  also  use 
MAXIMUM_VISIBILITY_ 

RANGE  from  Terrain  category  or  visibility 
distance  from  Weather  category. 

Segment_Concealment 

Degree  of  concealment  provided  for 
the  unit  by  the  terrain  in  that  AA 
segment. 

1 

float 

0..1  where  0  -  0%  and  1  =  100% 

Segment_Cover 

Degree  of  cover  provided  by  the 
terrain  for  unit  in  that  AA  segment. 

1 

float 

0..1  where  0  -  0%  and  1  =  100% 

GEOMETRY 

Spatial  representation  of  the  AA 
segment;  note  this  is  from  a  class  in 
the  Utilities  category. 

1 

float 

A  polygon. 

Table  D7.  Maneuver  Analysis  class:  KEY_TERRAIN.t 


Attribute  or  Associated  Class 

Definition 

Cardinality 

Data 

Type 

Units  of  Measure  /  other  notes 

Name 

Unique  name  identifier  for  this 
KEY_TERRAIN. 

1 

string 

A0_Name 

Unique  identifier  of  this  AO  associated 
with  this  KEY_TERRAIN. 

1 

string 

Key_Terrain_Type 

Description  of  the  KEY_TERRAIN  (e.g., 
building,  knoll). 

1 

string 

Could  be  parsed  into  preset  categories  and 
made  integer. 

Reason 

Reason  this  is  considered 

KEY_TERRAIN. 

1 

string 

F0RCE_DISP0SITI0N 

Affliation 

The  side  associated  with  with  this  key 
terrain;  F0RCE_DISP0SITI0N  is  a 
class  in  the  Forces  category  who  owns 
this  KEY_TERRAIN. 

1 

As  represented  by  Forces  category. 

*  AVENUE_OF_APPROACH_SEGMENT— Assumes  an  AA  is  made  up  of  distinct  segments  described  as  straight  lines  with 
segment  width. 

t  KEY_TERRAIN— "(DOD,  NATO)  Any  locality,  or  area,  the  seizure  or  retention  of  which  affords  a  marked  advantage  to  either 
combatant."  (FM  1-02;  HQDA  2003a.) 
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Attribute  or  Associated  Class 

Definition 

Cardinality 

Data 

Type 

Units  of  Measure  /  other  notes 

GEOMETRY 

Spatial  representation  of  the 

float 

KEY_TERRAIN  can  typically  be  represented  as 

KEY_TERRAIN;  note  this  is  from  a 
class  in  the  Utilities  category. 

1 

a  polygon. 

Table  D8.  Maneuver  Analysis  class:  ENGAGEMENT_AREA  (EA).* 


Attribute  or  Associated  Class 

Definition 

Cardinality 

Data 

Type 

Units  of  Measure  /  other  notes 

Name 

Unique  name  identifier  for  the 
ENGAGEMENT_AREA  (EA). 

1 

string 

A0_Name 

Unique  identifier  of  this  AO. 

1 

string 

AA_Name 

Unique  name  identifier  for  AA. 

1 

string 

Fire_Type 

Type  of  fire  to  employ. 

1 

string 

EnemyJJnit 

Enemy  unit  to  engage. 

1 

string 

Enemy_Fire_Type 

Expected  enemy  Fire_Type. 

1 

string 

Initiator 

Who  will  initiate  engagement? 

1 

integer 

0  =  friendly  unit 

1  =  enemy  unit 

F0RCE_DISP0SITI0N 

Identity 

Identity  of  the  friendly  unit  which 
will  engage  in  this  area; 
FORCE_DISPOSITION  is  a  class  in 
the  Forces  category  who  owns  this 
KEY_TERRAIN. 

1 

As  represented  by  Forces 
category. 

GEOMETRY 

Spatial  representation  of  the  EA; 

note  this  is  from  a  class  in  the 

Utilities  category. 

1 

float 

A  polygon. 

*  ENGAGEMENT_AREA  —"An  area  where  the  commander  intends  to  contain  and  destroy  an  enemy  force  with  the  massed 
effects  of  all  available  weapons  and  supporting  systems.  Also  called  EA."  (FM  1-02;  HQDA  2003a.) 
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Table  D9.  Maneuver  Analysis  class:  TIME_PHASE_LINE_H  (TPL).* 


Attribute  or  Associated 

Class 

Definition 

Cardinality 

Data 

Type 

Units  of  Measure  /  other  notes 

A0_Name 

The  unique  identifier  of  this  AO. 

1 

string 

Timejncrement 

Time  lapsed  relative  to  start  time  for 

the  movement. 

1 

float 

Time  in  minutes;  range  >=0  (note,  this  is  for 
tactical  level;  for  a  campaign  days  can  be  the 
unit  of  measure). 

TPL_PT_1 

Defines  the  line  segement  for  the 
time  phase  line  at  a  particular  time 

increment. 

1 

float 

TPL_PT_2 

Defines  the  line  segement  for  the 
time  phase  line  at  a  particular  time 

increment. 

1 

float 

This  can  be  carried  out  to  n  TPL_PT_n. 

GEOMETRY 

Spatial  representation  of  the  EA;  note 

this  is  from  a  class  in  the  Utilities 

category. 

1 

float 

Can  be  represented  as  a  line. 

FORCE_DISPOSITION 

Identity 

Affliation 

Identity  and  Side  associated  with  this 
TPL;  FORCE_DISPOSITION  is  a  class  in 
the  Forces  category  who  owns  this 
KEY_TERRAIN. 

1 

As  represented  by  Forces  category. 

*  TIME_PHASE_LINE_H— Lines  indicated  the  flow  of  the  operation  (based  on  a  course  of  action)  and  the  progression  of  units 
at  particular  time  intervals  relative  to  the  start  time  for  the  movement.  H-Hour  inidicates  start  typically  and  H+15 
indicate  progression  after  15  minutes  have  elapsed,  etc.  (FM  1-02;  HQDA  2003a.) 
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APPENDIX  E:  M-COP  ROUTE  FINDING 
CATEGORY 


Table  El.  Route  Finding  category  classes. 


Class 

Class  Definition 

Attributes 

Attribute  Definition 

Units 

Cardinality 

Source 

ROUTE 

Prescribed  course  to 

be  traveled  from  a 

specific  point  of 
origin  to  a  specific 

destination. 

FM  3-90 

Route_Purpose 

Usage  ROUTE  will  support  (i.e. 

MSR,  passing  route). 

(0,M) 

FM  3-90 

Route_ 

Classification 

Classification  assigned  to  a  route 
using  factors  of  minimum  width 
and  worst  ROUTE  type,  least 
bridge,  raft  or  culvert  military  load. 

(0,1) 

FM  5- 

100 

Start_Point 

Start  point  of  ROUTE. 

(1,1) 

BTRA 

Stop_Point 

End  point  of  ROUTE. 

(1,1) 

BTRA 

Edge_List 

An  ordered  list  of  EDGES  included 

in  this  ROUTE. 

(1,1) 

M-COP 

Maneuve 

r 

Analysis 

ROUTE_ 

REQUEST 

A  request  for  a 

ROUTE  through  a 

maneuver  network. 

M-COP 

Route 

Finding 

Start_Point 

Point  to  begin  ROUTE  search. 

(1,1) 

BTRA 

Stop_Point 

Point  to  end  ROUTE  search. 

(1,1) 

BTRA 

Way_Point 

Point  ROUTE  should  pass  near  or 

visit. 

(0,M) 

M-COP 

Route 

Finding 

Datetime 

A  point  in  time  that  designates  the 
beginning  of  the  period  of 
effectiveness  for  the  trafficability 
assessments  of  EDGES  in  which  to 

search  for  the  ROUTE. 

(0,1) 

BTRA 

Constraint_List 

CONSTRAINTS  included  in 
ROUTE_REQUEST. 

(0,M) 

M-COP 

Route 

Finding 

Constraint- 

Weight_List 

Weights  of  CONSTRAINTS. 

(0,M) 

M-COP 

Route 

Finding 

CONSTRAINT 

A  requirement  that 
should  be  met  by 

M-COP 

Route 
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Class 

Class  Definition 

Attributes 

Attribute  Definition 

Units 

Cardinality 

Source 

ROUTE. 

Finding 

Force 

Force  ROUTE  should 

accommodate.  This  would  imply 
such  requirements  as  overhead 
clearance,  minimum  turning 
radius,  width,  movement 
technique,  etc. 

(0,1) 

BTRA 

Constraint.Type 

Whether  this  CONSTRAINT  is  on 

time,  distance,  control-measure, 
GEOMETRY,  Feature,  or  Feature- 
Type. 

(1,1) 

M-COP 

Route 

Finding 

Control.Measure 

Unit  boundaries, 

ENGAGEMENT.AREAS,  phase  lines, 

etc  used  to  bound  or  otherwise 

constrain  ROUTE  search. 

(0,M) 

M-COP 

Maneuve 

r 

Analysis 

Geometry 

A  geospatial  object  used  to  bound 

or  otherwise  constrain  ROUTE 

search. 

(0,M) 

M-COP 

Route 

Finding 

Feature 

Feature(s)  specified  for  bounding 
or  otherwise  constraining  ROUTE 

search. 

(0,M) 

M-COP 

Route 

Finding 

Feature.Type 

Feature.Types(s)  specified  for 
bounding  or  otherwise  constraining 

ROUTE  search. 

(0,  M) 

M-COP 

Route 

Finding 

Obstacle 

Obstacle(s)  specified  for  bounding 
or  otherwise  constraining  ROUTE 

search. 

(0,M) 

M-COP 

Route 

Finding 

Obstacle.Type 

Obstacle.Types(s)  specified  for 
bounding  or  otherwise  constraining 

ROUTE  search. 

(0,M) 

M-COP 

Route 

Finding 

MANEUVER. 

NETWORK. 

GRAPH 

A  geometric 
representation  of 
trafficability  over 

terrain  that  can  be 

used  in  mobility  and 
maneuver  analysis 
applications. 

(1,M) 

BTRA 

Edge.List 

List  of  EDGES. 

(1,M) 

BTRA 

Node.List 

List  of  NODES. 

(2,M) 

BTRA 

Maneuver. 

Network.Type 

Describes  the  nature  of  this 

maneuver  network  graph  whether 
for  composed  of  main  supply 
routes,  on-road  only,  off-road  only, 

etc. 

(1,1) 

BTRA 

Network.Junction 

A  NODE  with  connecting  EDGES 

from  more  than  maneuver  network 

graph. 

(0,M) 

BTRA 

EDGE 

A  graph 

BTRA 

182 


ERDC  TR-07-4 


Class 

Class  Definition 

Attributes 

Attribute  Definition 

Units 

Cardinality 

Source 

representation  of 
contiguous  stretches 
of  terrain  having  like 

attributes  — 

especially 

trafficability. 

NodeA 

NODE  where  EDGE  end  designated 
as  “A"  terminates  (A,B  designation 
is  arbitrary). 

(1.1) 

BTRA 

NodeB 

NODE  where  EDGE  end  designated 
as  “B"  terminates  (A,B  designation 
is  arbitrary). 

(1.1) 

BTRA 

Feature 

Feature  represented  by  this  EDGE. 

(1,1) 

M-COP 

Terrain 

Width 

Width  of  trafficable  terrain. 

m 

(1,1) 

BTRA 

Off_Road_Shortest 

Weighted  cost  favoring  short  off¬ 
road  features. 

(1,1) 

BTRA 

On_Road_Shortest 

Weighted  cost  favoring  short  road 

features. 

(1,1) 

BTRA 

Military_Load 

-Classification 

General_Vehicle_ 

Type_Speed 

Assessed  speed  of  a 
General_Vehicle_Type  over  this 

EDGE. 

m  /  s 

(12,  M) 

BTRA 

General-Vehicle- 

Type-Time 

Weighted  cost  reflecting  time 
required  for  a 

General_Vehicle_Type  to  traverse 

this  EDGE. 

(12,  M) 

BTRA 

General_Vehicle_ 

Type_Off_Road_ 

Fastest 

Weighted  cost  favoring  fastest  off¬ 
road  EDGES  for  a 

General_Vehicle_Type. 

(12,  M) 

BTRA 

General_Vehicle_ 

Type_On_Road_ 

Fastest 

Weighted  cost  favoring  fastest  on¬ 
road  EDGES  for  a 

General_Vehicle_Type. 

(1,1) 

BTRA 

Concealment 

Weighting  of  concealment. 

(1,1) 

BTRA 

Radius 

_of_Curvature 

Most  narrow  curve  along  EDGE. 

m 

(1,1) 

URBAN 

Assessment- 
Eff  ecti  ve_Dateti  m  e 

The  character  string  representing  a 
point  in  time  that  designates  the 
beginning  of  the  period  of 
effectiveness  for  a  specific  EDGE. 

(1,1) 

BTRA 

NODE 

An  endpoint  of  a 
graph  EDGE. 

BTRA 

Geometry 

A  geometric  representation  of  the 

NODE. 

M-COP 

Utility 

Edge 

EDGE  terminating  at  this  NODE. 

(1,M) 

BTRA 

FORCE 

A  group  of  ground 

M-COP 
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Class 

Class  Definition 

Attributes 

Attribute  Definition 

Units 

Cardinality 

Source 

vehicles. 

Width 

Width  of  FORCE  while  traveling. 

m 

(0,1) 

BTRA 

Formation_Type 

(0,1) 

M-COP 

Force 

Vehicle_Type 

(0,M) 

BTRA 

General_Vehicle_ 

Type 

(0,M) 

BTRA 
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APPENDIX  F:  NATO  REFERENCE  MOBILITY 
MODEL  (NRMM)  VEHICLE  SCHEME  2.0  (June 
2003) 


The  NATO  Reference  Mobility  Model  (NRMM)  is  the  Army  Modeling  and 
Simulation  Office  standard  for  single  vehicle  ground  movement 
representation  (Ahlvin  and  Haley  1992).  A  Standard  Mobility  (STNDMob) 
Application  Program  Interface  (API)  has  been  developed  based  on  the 
NRMM  to  incorporate  terrain-limited  vehicle  speed  determinations  into 
M&S  systems  (Baylot  et  al.  2005).  An  extensive  XML  schema 
representation  of  the  NRMM  is  available  for  general  use,  in  addition  to  the 
STNDMob  API  software  implementation,  XML  schema,  and  XML  data 
files.  An  overview  of  Version  2.0  of  the  NRMM  vehicle  XML  schema  is 
provided  below.  Appendix  G  contains  an  example  XML  file  storing  NRMM 
vehicle  data  for  the  M1A1  Abrams  tank  in  accordance  with  this  schema. 


schema  location: 

attribute  form  default: 

NRMMVehicleSchema_2.0.xsd 

element  form  default: 

qualified 

Elements 

Complex  types 

Simple  types 

Comment 

AssemblyType 

DescriptionType 

Name 

ConfigurationType 

Name60LettersType 

PreComment 

FloatArrayType 

unitAngle 

SourceReference 

FloatValueType 

unitArea 

Vehicle 

IntegerArrayType 

unitCorneringStiffness 

IntegerValueType 

unitDisplacement 

StringArrayType 

unitForce 

StringValueType 

unitLength 

TrackSetAssemblyType 

unitPower 

UnknownAssemblyType 

unitPressure 

WheeledAxleAssemblyType 

unitRevPerDistance 

unitRMSDistance 

unitSpeed 

unitStiffness 

unitTorque 

unitWeight 
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element  Comment 


diagram 

Comment 

type 

xsd:string 

properties 

content  simple 

element  Name 


diagram 

F - 

Name 

type 

xsdistring 

properties 

content 

simple 

element  PreComment 


diagram 

PreComment 

type 

xsd:string 

properties 

content  simple 

element  SourceReference 


diagram 

SourceReference 

type 

xsd:string 

properties 

content  simple 
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element 

Vehicle 


diagram 
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Properties 

content  complex 

children 

Name  Description  NAMBLYPreComment  NAMBLYComment  NAMBLYSourceRef 

NVUNTSPreComment  NVUNTSComment  NVUNTSSourceRef  NSUSPPreComment  NSUSPComment 
NSUSPSourceRef  SourceReference  Configuration  Assembly  VehicleObstacleData 

attributes 

Name 

Type  Use 

Default 

Fixed  Annotation 

xmlCreatedBy 

xsd:string 

xmlSchemaVersion 

xsd:string 

dimensionalUnits 

derived 

English 

documentation 

by: 

xsd:string 

'91  VEHSIU:  Vehicle 
data  input  unit  Sl-units 
code: 

0=U.S.  customary, 

1=S.I. 

0  =  Vehicle  data 
specified  in  english 
units  [default] 

1  =  Vehicle  data 
specified  in  metric  (SI) 
units 

numAssembly 

xsd:int 

documentation 

'49  NAMBLY:  #  of 

traction  element 
assemblies  (axles  and 
tracks) 

numVehiclellnitsInCombi 

xsd:int 

1 

documentation 

nation 

'62  NVUNTS:  #  of 
units  ( tractors  and 
trailers  etc. )  in  vehicle 
combination 

numSuspensionSpring 

xsd:int 

documentation 

'59  NSUSP:  #  of 
suspension  springs 
for  side-slope  (0  =  no 
side  slope  analysis) 

reqSecurityClass 

derived 

U 

documentation 

by: 

xsd:string 

Security  Classification 

Code 

annotation  documentation 


The  Vehicle  element  is  the  base  element  of  an  NRMM  XML  file.  It  consists  of  three  sections.  The  first 
section  is  a  header  containing  a  vehicle  name  element  and  its  description.  The  second  section  is  a 
configuration  block  which  contains  elements  that  describe  the  entire  vehicle.  The  last  section  has  one 
or  more  elements  of  "Assemblies'';  each  assembly  can  be  a  tracked  or  wheeled  or  something  that  has 
not  been  seen  yet. 


188 


ERDC  TR-07-4 


ERDC  TR-07-4 


189 


children  ASMPreComment  ASMComment  ASMSourceRef  ASMPwrPreComment  ASMPwrComment 

ASMPwrSourceRef  ASMBrakePreComment  ASMBrakeComment  ASMBrakeSourceRef 
MinGroundClearancePerAssembly  ChassisToAxle  HardSurfaceMotionResistance 
AvgSuspensionStiffness  FineGrainSoilVehicleConelndex  CenterToCenterTreadWidth 
AssemblyWeight  MinAssemblyWidth  WheelRevPerDistance  TrackSetAssembly 
WheeledAxleAssembly  UnknownAssembly 


attributes 

Name 

Type 

Use  Default 

Fixed 

Annotation 

isAssemblyPow 

derived  by: 

documentation 

ered 

xsd:string 

'35  IP(NAMBLY) 

Traction  assembly 
powered  code: 

0  =  not  powered, 

1  =  powered 

isAssemblyTow 

derived  by: 

documentation 

ed 

xsd:string 

This  attribute  indicates  if 
an  assembly  is  towed  or 

not. 

isAssemblyBrak 

derived  by: 

documentation 

eAvailable 

xsd:string 

'28  IB(NAMBLY): 

Traction  assembly 
braked  code 

0  (no)  =  assembly  is  not 
braked 

1  (yes)=  assembly  is 
braked 

annotation  documentation 


The  followings  are  implicit  variables  now: 

'61  NVEH(NAMBLY)  Vehicle  traction  assembly  type  code  for  each  assembly: 
'  0  =  assembly  is  a  track 

'  1  =  assembly  Is  wheeled 


complexType  ConfigurationType 


diagram 


ConfigurationType  [^)— 

Fordinglnformation  [+] 

PhysicalCharacteristics 


Enginelnformation 


JJ3 


Transmissionlnformation 


O  b  s tac  I  e  Defl  ecti  on  I  nf  o  rmati  on 


5 


children 


PhysicalCharacteristics  Enginelnformation  Fordinglnformation  Transmissionlnformation 
ObstacleDeflectionlnformation 
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complexType  FloatArrayType 


diagram 


’-■>  Value  !■ 

1  i1 

0.x 


^FloatArrayType  ' 


PreComment  !; 

0..X 

.=■  r 

[•--!  Comment 


0..x 


L--l  SourceReference  ;• 

>  ,4 

0.x 


children 


Value  PreComment  Comment  SourceReference 


complexType  FloatValueType 


diagram 


(^FloatValueType 


S  attributes 

;  value  : 


-I"  PreComment  !)| 

i! 

v.v.v.v.v.v.v.-.1 

0.x 


*--f  Comment  ;! 
•  .*  . 
■  --------------- 

0..x 


— !  SourceReference  !■ 
>  .■ 
.v/.v/.-.v-v/.-.v,.' 

0..x 


children 


PreComment  Comment  SourceReference 


attributes 


Name 

value 


Type 

xsd:float 


Use 


Default 


Fixed  Annotation 


complexType  IntegerArrayType 


diagram 


-  -i  PreComment  1 

if _ ;  | 

[^IntegerArrayType  |^Hj— — 


—  Value 


— “v 

1..x 


0.x 


[■--!  Comment  'I 

ii 

r.V.V.V.VJT.V  ^ 

0.x 


SourceReference 

> 


0..x 


children 


Value  PreComment  Comment  SourceReference 
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complexType  IntegerValueType 


diagram 


IntegerValueType  H- 


B  attributes 

I  "ji 

;  value  I 


r-t  PreComment  ■: 

_ j 


MSb- 


0..x 


Comment  'I 

■  'i 


0..x 


'---i  SourceReference  !■ 

r.v.v.v.v.v.v.v.v.-.  • 
0..x 


children 


PreComment  Comment  SourceReference 


attributes 


Name 

value 


Type 

xsd:int 


Use 


Default 


Fixed 


Annotation 


complexType  StringArrayType 


diagram 

Value 

1..0D 

[  StringArrayType  [^)— (  —  ^[— 

's  "S 

— !  PreComment 

0.x 

MSB- 

'=  r 

-  -!  Comment  'i 

!i 

0..® 

--f  SourceReference  jj 

0..K 

children 

Value  PreComment  Comment  SourceReference 

192 


ERDC  TR-07-4 


complexType  StringValueType 


diagram 


fstri 


StringValueType 


0  attributes 

;  value  ; 


Lee- 


--I  PreComment 

0..x 


Comment 

_ 


0..x 


--!  SourceReference 
> 


0..x 


children 


PreComment  Comment  SourceReference 


attributes 


Name 

value 


Type 

xsd:string 


Use 


Default 


Fixed 


Annotation 
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complexType 

TrackSetAssemblyType 


diagram 


width  (one  side)  for  each 
tracked  assembly  [in]  (m) 
□  □□□□ 
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children 

TRKFlexPreComment  TRKFlexComment  TRKFlexSourceRef  TRKPadPreComment  TRKPadComment 

TRKPadSourceRef  TrackShoeArea  TrackGrouserHeight  NumTrackRoadWheel 

TrackBogieEffectiveRadius  TrackGroundLength  TrackWidth 

attributes 

Name  Type  Use  Default  Fixed  Annotation 

isTrackFlexible  derived  by:  documentation 

xsd:string  '54  NFL(NAMBLY) 

Flexible  track  type 

code: 

0  (no)  =  track  is 
not  flexible  (i.e. 
girderized  like 
dozer  etc.) 

1  (yes)  =  track  is 
flexible  (i.e.  tank 
etc.) 

doesTrackHavePad  derived  by:  documentation 

xsd:string  ,5g 

NPAD(NAMBLY) 

Track  pad  code  for 
each  assembly 

0  (no)  =  track  does 
not  have  pads 

1  (yes)=  track  has 
pads 

complexType  UnknownAssemblyType 


diagram 

---1  PreComment  !; 

• 

V.-.V.V.V.-.V.V.-.1 

0..x 

(^UnknownAssemblyType  [^)— (-»*■ 

■--!  Comment  'll 
!. 

0..® 

'=  \ 

---!  SourceReference  I* 

0..® 

children 

PreComment  Comment  SourceReference 
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children 

TireTypePreComment  TireTypeComment  TireTypeSourceRef  DualTirePreComment 

DualTireComment  DualTireSourceRef  TireStiffPreComment  TireStiffComment 

TireStiffSourceRef  TireChainPreComment  TireChainComment  TireChainSourceRef  NumTires 

TireAspectRatio  TirePlyRating  AvgTireCorneringStiffness  AxleSpacing  TireUndeflectedDiameter 
TireUndeflectedHeight  TirellndeflectedWidth  TireRimDiameter  TireRimWidth  TireDeflection 
TirelnflationPressure  TandemAxle  EquivalentSingleWheelLoad  TireNomenclature 

attributes 

Name  Type  Use  Default  Fixed  Annotation 

isTireRadialType  derived  by:  documentation 

xsd:string  ,2g 

ICONST(NAMBLY): 

Tire  type 

construction  code 

0  =  Tire 

construction  is 

radial 

1  =  tire 

construction  is 

bias 

isDualTire  derived  by:  documentation 

xsd:string  ,32  id(NAMBLY): 

Dual  tire  flag  for 
each  assembly 

0  (no)  =  tires  on 
assembly  are  not 
duals  (i.e.  singles) 

1  (yes)=  tires  on 
assembly  are 

duals 

tireStiffness  derived  by:  documentation 

xsd:string  ,43 

KTSFLG(NAMBLY): 

Tire  stiffness  code 

for  each  assembly: 

0  =  no  stiffness 

considered 

1  =  tires  are 

"flexible"  (  25% 

defl.  r-res  less  than 

0.02  ) 

2  =  tires  are 

"medium"  ( 25% 

defl.  r-res  less  than 

0.035  ) 

3  =  tires  are  "stiff"  ( 

25%  defl.  r-res 
greater  than  or 
equal  to  0.035  ) 

isTireChained  derived  by:  documentation 

xsd:string  ,51 

NCHAIN(NAMBLY): 

Tire  chain  traction 

assist  flag: 

0  (no)  =  tires  do  not 
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have  chains 
1  (yes)=  tires  have 
chains 


simpleType  DescriptionType 


type 

xsd:string 

annotation 

documentation 

The  Desccription  element  type  can  have  unlimited  number  of  charaters  to  describe  a 

vehicle  in  detail. 

simpleType  Name60LettersType 


type 

restriction  of  xsd:string 

facets 

minLength  1 

maxLengt  60 
h 

annotation 

documentation 

By  rule,  the  first  line  of  NRMM  file  only  can  hold  no  more  than  60  characters  to  describe 
a  vehicle  name. 

simpleType  unitAngle 


type 

restriction  of  xsd:string 

facets 

enumeratio 

n 

deg 

enumeratio 

n 

rad 

simpleType  unitArea 


type 

restriction  of  xsd:string 

facets 

enumeration 

inA2 

enumeration 

ftA2 

enumeration 

cmA2 

enumeration 

mA2 

simpleType  unitCorneringStiffness 


type 

restriction  of  xsd:string 

facets 

enumeration  Ib/deg 

enumeration  N/rad 
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simpleType  unitDisplacement 


type 

restriction  of  xsd:string 

facets 

enumeration 

inA3 

enumeration 

ftA3 

enumeration 

cmA3 

enumeration 

mA3 

simpleType  unit  Force 


type 

restriction  of  xsd:string 

facets 

enumeration  lb 

enumeration  N 

simpleType  unitLength 


type 

restriction  of  xsd:string 

facets 

enumeration  in 

enumeration  ft 

enumeration  cm 

enumeration  m 

simpleType  unitPower 


type 

restriction  of  xsd:string 

facets 

enumeration  watts 

enumeration  HP 

simpleType  unitPressure 


type 

restriction  of  xsd:string 

facets 

enumeration  psi 

enumeration  N/mA2 

simpleType  unitRevPerDistance 


type 

restriction  of  xsd:string 

facets 

enumeration  rev/Mi 

enumeration  rev/m 

simpleType  imitRMSDistance 


type 

restriction  of  xsd:string 

facets 

enumeration  RMS-in 

enumeration  RMS-m 
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simpleType  unitSpeed 


type 

restriction  of  xsd:string 

facets 

enumeration 

fps 

enumeration 

MPH 

enumeration 

mps 

enumeration 

KPH 

simpleType  unitStiffness 


type 

restriction  of  xsd:string 

facets 

enumeration  Ib/in 

enumeration  N/m 

simpleType  unitTorque 


type 

restriction  of  xsd:string 

facets 

enumeration  ft-lb 

enumeration  N-m 

simpleType  unitWeight 


type 

restriction  of  xsd:string 

facets 

enumeration  lb 

enumeration  kg 
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APPENDIX  G:  M1A1  DATA  USING  THE  NATO 
REFERENCE  MOBILITY  MODEL  (NRMM) 
VEHICLE  SCHEMA  2.0  (June  2003) 


The  NATO  Reference  Mobility  Model  (NRMM)  is  the  Army  Modeling  and 
Simulation  Office  standard  for  single  vehicle  ground  movement 
representation  (Ahlvin  and  Haley  1992).  A  Standard  Mobility  (STNDMob) 
Application  Program  Interface  (API)  has  been  developed  based  on  the 
NRMM  to  incorporate  terrain-limited  vehicle  speed  determinations  into 
M&S  systems  (Baylot  et  al.  2005).  An  extensive  XML  schema 
representation  of  the  NRMM  is  available  for  general  use,  in  addition  to  the 
STNDMob  API  software  implementation,  XML  schema,  and  XML  data 
files.  An  overview  of  Version  2.0  of  the  NRMM  vehicle  XML  schema  is 
provided  in  Appendix  F.  An  example  XML  file  storing  NRMM  vehicle  data 
for  the  M1A1  Abrams  tank  in  accordance  with  this  schema  is  provided 
below 


<?xml  version="l.o"  encoding="utf-8"  ?> 

<?xml-stylesheet  type="text/xsl"  href="NRMMVehicleXSL_2.o.xsl"  ?> 

<!— 

Agency:  Army  Materiel  Systems  Analysis  Activity 

U.S.  Government  employees  and  contractors  generated  this  product,  and  the  overnment  has  format  and  data  rights  therein  for  government  purposes. 

Should  the  contractor  obtain  a  copyright  in  the  product,  those  sections  developed  solely  by  government  employees  should  be  designated  so  that  one  is 
on  notice  that  no  copyright  exists  for  those  portions  of  the  product  generated  solely  by  government  employees. 

— > 

<Vehicle  xmlCreatedBy="AMSAA"  xmlSchemaVersion="2.o"  dimensionalUnits="English"  numAssembly="l"  numVehicleUnitsInCombination="l"  numSuspensionSpring="o" 
reqSecurityClass="U"> 

<Name>  < ! [CDATA[MlAl  ABRAMS  TANK  (WES  Standard)  JHL]]x/Name> 

<Descriptionx![CDATA[Project:  Standard  vehicle 
Date  entered:  7  Dec  '93  RBA  &  NRMM-mgr 
Date  updated:  10  Feb  '94  RBA,  NRMM-mgr 
File  name:  M1A1.STD 
Description: 

M1A1  ABRAMS  TANK  (WES  Standard) 

]]> 

</Description> 

<NAMBLYSourceRefx !  [CDATAQust  test  ]]  >  < /NAMBLYSourceRef> 

<NSUSPCommentx![CDATA[  to  be  derived  from  VEHDYN  data]]x/NSUSPComment> 

<Configuration> 

<  PhysicalCharacteristics> 

<AerodynamicDragCoefficient  value="l.2"> 

<PreCommentx![CDATA[  ACD  =  0.8  !  WES,  unknown  origin]]x/PreComment> 

<Commentx![CDATA[  (worst  case  rectangular  plate)]]x/Comment> 

</AerodynamicDragCoefficient> 

<CGToGround  value="53.04"  unitlnfo="in"> 

<PreCommentx![CDATA[  CGH  =  52.1 !  WES,  PM  ofc  26Jun89]]x/PreComment> 

<PreCommentx![CDATA[  CGH  =  52.0  !  TM55-2350-255-14, ’79]]></PreComment> 

< Comment x![CDATA[  PM  ofc,  l99l]]x/Comment> 

< /CGToGround> 

<CGToCenterLine  value="l.82"  unitlnfo="in"> 

<PreCommentx![CDATA[  CGLAT  =  0.0  !  WES,  unknown  origin]] ></PreComment> 

<PreCommentx![CDATA[  CGLAT  =  1.2  !  TM55-2350-255-14  '79]]x/PreComment> 

< Comment x![CDATA[  PM  ofc,  l99l]]x/Comment> 

< /CGToCenterLine> 

<CGToRearAxle  value="l00.55"  unitInfo="in"> 

<PreCommentx![CDATA[  CGR  =  100.3  !  WES,  unknown  origin]] ></PreComment> 

<Commentx !  [CDATA[  TM55-2350-255-14  '79]]  >  < / Comment> 

< /CGToRearAxle> 

<MinGroundClearance  value="l7"  unitlnfo="in"> 

< PreComment x![CDATA[  CGR;  PM  ofc,  1991,  I26.0lin  =  H-dist  C-G  to  final  drive  (rear  sprocket)]]  x/PreComment> 
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<PreCommentx![CDATA[  CL  =  19.0  !  TM55-2350-255-14  ’79]]x/PreComment> 
<Commentx![CDATA[  JANE'S  1990-91  &  PM  ofc  l99l]]x/Comment> 

< /MinGroimdClearance> 

<DriverEyeHeight  value="59"  unitlnfo="in"> 

<PreCommentx![CDATA[  EYEHGT  =  60  !  WES,  unknown  origin]] x/PreComment> 

<Commentx !  [CDATA[  TM55-2350-255-14  '79]]  >  < / Comment> 

< /DriverEyeHeight> 

<FrontalArea  value="78"  unitInfo="inA2"> 

<PreCommentx![CDATA[  PFA  =  76  !  WES,  unknown  origin]] ></PreComment> 
<PreCommentx![CDATA[  PFA  =  80  !  TM55-2350-255-14 '79]]x/PreComment> 

< Comment x![CDATA[  PM  ofc,  l99l]]x/Comment> 

</FrontalArea> 

<MaxPushBarForce  value="252000"  unitInfo="lb"> 

<Commentx![CDATA[  estimated  as  2*GVW]]x/Comment> 

< /MaxPushBarForce> 

<PushBarHeight  value="46.8"  unitlnfo="in"> 

<PreCommentx![CDATA[  PBHT  =  44.5  !  WES,  unknown  origin]] x/PreComment> 
<Comment>  < !  [CDATA[  TM55-2350-255-14  '79]]  >  < / Comment> 

< /PushBarHeight> 

<ApproachAngle  value="22"  unitInfo="deg"> 

<Comment>  < !  [CDATA[  TM55-2350-255-14  '79]]  >  < / Comment> 

</ApproachAngle> 

<RideTolerance  value="o"  unitInfo="G"  /> 

<MaxDepartureAngle  value="36"  unitlnfo="deg"> 

<Comment>  < !  [CDATA[  TM55-2350-255-14  '79]]  >  < / Comment> 

< /MaxDepartureAngle> 

<MilitaryLoadClass  value="o"  /> 

<MaxSpeedOnVegetatedSlopeBeforeSliding  value="o"  unitInfo="MPH"  /> 
<MaxSpeedOnVegetatedSlopeBeforeTipping  value="o"  unitInfo="MPH"  /> 

<WinchCapacity  value="o"  unitInfo="lb"> 

<Commentx![CDATA[  TARDEC,  unknown  origin]]  x/Comment> 

< /WinchCapacity> 

<MaxVehicleWidth  value="l43.76"  unitlnfo="in"> 

<PreCommentx![CDATA[  WDTH  =  144  !  JANE'S  1990-91  &  PM  ofc  1991]] ></PreComment> 
<PreCommentx![CDATA[  WDTH  =  143.80  !  FSP83-025,  Apr'83]]x/PreComment> 
<Comment>  < !  [CDATA[  TM55-2350-255-14  '79]]  >  < / Comment> 

< /MaxVehicleWidth> 

<CombinationVehicleBrakingCoefficient  value=".55"> 

<PreCommentx![CDATA[  XBRCOF=  0.40  !  WES,  unknown  origin]]x/PreComment> 
<PreCommentx![CDATA[  XBRCOF=  0.80  !  NRMM-mgr  M1A2  Jul'93]]x/PreComment> 
<Commentx![CDATA[  APG  REPORT  #  9l-LR(F)~3,  test  results  for  MlEl]]x/Comment> 
</CombinationVehicleBrakingCoefficient> 

<FirstWheelCenterToLastWheelCenter  value="l8o.o8"  unitlnfo="in"> 
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<PreCommentx![CDATA[  TL  =180.1  !  WES,  FSP83-025,  Apr'83  (rounded  off)]] ></PreComment> 

<PreCommentx![CDATA[  TL  =180.0  !  TM55-2350-255-14  '79]]x/PreComment> 

< Comment x![CDATA[  FSP83-025,  Apr’83]]x/Comment> 

</FirstWheelCenterToLastWheelCenter> 

<VehicleLength  unitInfo="in"> 

<Value>3ll.68</Value> 

<PreCommentx![CDATA[  VULEN  =  190  !  Old  WES,  unknown  origin]]x/PreComment> 

<PreCommentx![CDATA[  VULEN(l)=  312  !  JANE'S  l990-9l]]x/PreComment> 

< Comment x![CDATA[  FSP83-025,  Apr’83]]x/Comment> 

< /VehicleLength> 

< /PhysicalCharacteristics> 

<  Enginelnformation  > 

<Engines  numEng="l"  powerUnit="HP"  torqueUnit="ft-lb"  displacementUnit="inA3"> 

<EachEngine  netEngPower="l50o"  maxEngTorque="3825"  engDisplacement="l500"  engType="turbine"  numEngCylinder="8"  /> 
<PowerCommentx![CDATA[  gross  HP,  PM  ofc  l99l]]x/PowerComment> 

<MaxTorquePreCommentx![CDATA[  QMAX(l)  =3940  !  WES  &  PM  ofc  l99l]]x/MaxTorquePreComment> 
<MaxTorqueCommentx![CDATA[  Allison  SCAAN  Jan  16  ’9l]]x/MaxTorqueComment> 

<DisplacementPreCommentx![CDATA[  CID  =  1360  !  TARDEC  Diesel  equivalent,  unknown  origin]] x/DisplacementPreComment> 
<DisplacementCommentx![CDATA[  WES,  Use  rated  horsepower  for  turbine  engine]]  x/DisplacementComment> 
<EngTypeCommentx![CDATA[  l=Gas, 4-stroke  diesel,  2=2-stroke  diesel,  3=turbine(Ml)]]x/EngTypeComment> 
<NumCylinderPreCommentx![CDATA[  HPNET  =1152  !  Allison  SCAAN  Jan  16 ’9l]]x/NumCylinderPreComment> 
<NumCylinderPreCommentx![CDATA[  NCYL  =  1  !  WES,  unknown  origin]] ></NumCylinderPreComment> 
<NumCylinderPreCommentx![CDATA[  NCYL  =  12  !  TARDEC,  unknown  origin]]x/NumCylinderPreComment> 
<NumCylinderCommentx![CDATA[  Correct  number  for  Ml  gas  turbine  (i.e.  IDIESL=3)]]x/NumCylinderComment> 

</Engines> 

<EngSpeedVsEngTorque  numPairsEngSpeedVsEngTorque="ll"  engSpeedUnit="RPM"  engTorqueUnit="ft-lb"> 

<Pair  engSpeed="8oo"  engTorque="l35o"  /> 

<Pair  engSpeed="looo"  engTorque="l650"  /> 

<Pair  engSpeed="l200"  engTorque="200o"  /> 

<Pair  engSpeed="l400"  engTorque="2300"  /> 

<Pair  engSpeed="l500"  engTorque="2450"  /> 

<Pair  engSpeed="l500"  engTorque="392o"  /> 

<Pair  engSpeed="l6oo"  engTorque="38so"  /> 

<Pair  engSpeed="2000"  engTorque="3550"  /> 

<Pair  engSpeed="2400"  engTorque="324o"  /> 

<Pair  engSpeed="28oo"  engTorque="29lo"  /> 

<Pair  engSpeed="2900"  engTorque="275o"  /> 

<PreCommentx![CDATA[  TARDEC  origin  unknown]]x/PreComment> 

< /EngSpeedVsEngTorque> 

< /Enginelnformation> 

<FordingInformation> 

<HydrodynamicDragCoefficient  value="l.2"> 

<PreCommentx![CDATA[  NSVALS  =  7  NRMM-mgr  M1A2  Jul’93;  not  used  in  NRMM-II]]x/PreComment> 
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<PreCommentx![CDATA[  SVALS  =  60  120  180  240  300  360  42o]]x/PreComment> 
<PreCommentx![CDATA[  VOOBS  =  18.4  18. 0  18. 0  10.6  12.9  16.1  l7.8]]x/PreComment> 
<PreCommentx![CDATA[  CD  =  0.7  !  WES,  unknown  origin]] ></PreComment> 
<Commentx![CDATA[  TARDEC  origin  unknown]]  x/Comment> 

< /HydrodynamicDragCoefficient> 

<CombinationVehicleDraft  value="o"  unitInfo="in"> 

<Commentx![CDATA[  TM55-2350-2555-14  '79]]></Comment> 

< /CombinationVehicleDraft> 

<SwampAngleEgress  value="o"  unitlnfo="deg"> 

<PreCommentx![CDATA[  FORDD  =  96  !  w/kit,  PM  ofc,  l99l]]x/PreComment> 
<Commentx![CDATA[  TARDEC,  unknown  origin]]  x/Comment> 

< /SwampAngleEgress> 

<SwampAngleIngress  value="o"  unitlnfo="deg"> 

<Commentx![CDATA[  TARDEC,  unknown  origin]]  x/Comment> 

< /SwampAngleIngress> 

<MinWaterDepthForAuxilliaryPropulsion  value="o"  unitlnfo="in"> 

<Commentx![CDATA[  TARDEC,  unknown  origin]]  x/Comment> 
</MinWaterDepthForAuxilliaryPropulsion> 

<MaxFordingDepth  value="48"  unitlnfo="in"> 

<PreCommentx![CDATA[  FORDD  =  50  !  TM55-2350-2555-14  ’79]]></PreComment> 
<Commentx![CDATA[  w/o  kit,  PM  ofc,  l99l]]x/Comment> 

< /MaxFordingDepth> 

<MaxFordingSpeed  value="o"  unitInfo="MPFI"> 

<Commentx![CDATA[  TARDEC,  unknown  origin]]  x/Comment> 

< /MaxFordingSpeed> 

<MaxSwimSpeedWithoutAuxilliaryPropulsion  value="o"  unitInfo="MPH"> 

<Commentx![CDATA[  TARDEC,  unknown  origin]]  x/Comment> 
</MaxSwimSpeedWithoutAuxilliaryPropulsion> 

<MaxSwimSpeedWithAuxilliaryPropulsion  value="o"  unitInfo="MPH"> 

<Commentx![CDATA[  TARDEC,  unknown  origin]]  x/Comment> 
</MaxSwimSpeedWithAuxilliaryPropulsion> 

<GroundToFordingWeightRatio  value="o"> 

< Comment x![CDATA[  TARDEC  Circa  '8l]]x/Comment> 

< /GroundToFordingWeightRatio> 

<WaterDepthVsWeightRatio  numPairsWaterDepthVsWeightRatio="2o"  waterDepthUnit="in"> 

<Pair  waterDepth="o"  weightRatio=".95"  /> 

<Pair  waterDepth="l8"  weightRatio=".903"  /> 

<Pair  waterDepth="22.l94"  weightRatio=".855"  /> 

<Pair  waterDepth= "26.389"  weightRatio=".8o8"  /> 

<Pair  waterDepth="30.583"  weightRatio=".76"  /> 

<Pair  waterDepth="34.778"  weightRatio=".7l3"  /> 

<Pair  waterDepth="38.972"  weightRatio=".666"  /> 

<Pair  waterDepth="43.l67"  weightRatio=”.6l8"  /> 
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<Pair  waterDepth= "47.361"  weightRatio=".57"  /> 

<Pair  waterDepth="5l.556"  weightRatio=".523"  /> 

<Pair  waterDepth="55.75"  weightRatio=".48"  /> 

<Pair  waterDepth="59.944"  weightRatio=".428"  /> 

<Pair  waterDepth="64.l39"  weightRatio=".38"  /> 

<Pair  waterDepth="68.333"  weightRatio=".333"  /> 

<Pair  waterDepth="72.528"  weightRatio=".285"  /> 

< Pair  waterDepth= "76.722"  weightRatio=".238"  /> 

<Pair  waterDepth="8o.9l7"  weightRatio=".lll"  /> 

<Pair  waterDepth="85.lll"  weightRatio=".s6"  /> 

<Pair  waterDepth="89.306"  weightRatio="o"  /> 

<Pair  waterDepth="93.5"  weightRatio="o"  /> 

<NWRPreCommentx![CDATA[  NRMM-mgr  M1A2  Jul'93]]x/NWRPreComment> 

<NWRCommentx![CDATA[  Tardec  Circa  '8l]]x/NWRComment> 

< /WaterDepthVsWeightRatio> 

< /Fordinglnformation> 

<TransmissionInformation  transmissionType="automatic/hydraulic"  hasLockingDifferential="true"  hasTorqueConverterLockup="true"> 
<XmtTypePreCommentx![CDATA[  ITCASE  =  o,  not  used  in  NRMM-II]]x/XmtTypePreComment> 

<XmtTypePreCommentx !  [CDATA[  ITRAN  =  1,  not  used  in  NRMM-II]]  >  < /XmtTypePreComment> 

<XmtTypeCommentx![CDATA[  o=shifts  automatically,  1  =  shifts  manually]]x/XmtTypeComment> 

<  FinalDriveGearRatio  value= "4.67"  > 

< Comment x![CDATA[  WES,  Allison  SCAAN  Jan  16  '9l]]x/Comment> 

<Commentx !  [CDATA[  TARDEC  origin  unknown]]  >  < / Comment> 

< /FinalDriveGearRatio> 

<FinalDriveEfficiency  value=".94"  /> 

<  EngToTorqueConverterGear  Ratio  value= "1"  > 

<Commentx![CDATA[  Null  engine-to-transmission  gear]]x/Comment> 

< /EngToTorqueConverterGearRatio> 

<EngToTorqueConverterEfficiency  value="l"  /  > 

<ConstantTorqueInput  value="300"  unitInfo="ft-lb"> 

<Commentx![CDATA[  TARDEC,  unknown  origin]]  x/Comment> 

< /ConstantTorqueInput> 

<TorqueConverterMultiplierVsEngSpeed  numPairsTorqueConverterMultiplierVsEngSpeed="l9"  engSpeedUnit=”RPM"  engTorqueUnit="Q-Multiplier"> 
<Pair  engSpeed="l840"  engTorque="o"  /> 

<Pair  engSpeed="i8oo"  engTorque=".i"  /> 

<Pair  engSpeed="l76o"  engTorque=".2"  /> 

<Pair  engSpeed="l740"  engTorque=".3"  /> 

<Pair  engSpeed="l740"  engTorque=".4"  /> 

<Pair  engSpeed="l740"  engTorque=".446"  /> 

<Pair  engSpeed="l76o"  engTorque=".5”  /> 

<Pair  engSpeed="l790"  engTorque=".548"  /> 

<Pair  engSpeed="l790"  engTorque=".55"  /> 

<Pair  engSpeed="l840"  engTorque=".6"  /> 
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<Pair  engSpeed="l905"  engTorque=".65"  /> 

<Pair  engSpeed="l98o"  engTorque=".7"  /> 

<Pair  engSpeed="2o6o"  engTorque=".75"  /> 

<Pair  engSpeed="2l50"  engTorque=".8"  /> 

<Pair  engSpeed="226o"  engTorque=".85"  /> 

<Pair  engSpeed="2395"  engTorque=".9"  /> 

<Pair  engSpeed="2470"  engTorque=”.92"  /> 

<Pair  engSpeed="2555"  engTorque=".935"  /> 

<Pair  engSpeed="268o"  engTorque=".95"  /> 

<ICONVlCommentx![CDATA[  TARDEC,  unknown  origin]]  x/ICONVlComment> 

<  /T  orqueConverterMultiplierV  sEngSpeed> 

<TorqueConverterMultiplierVsEngSpeedRatio  numPairsTorqueConverterMultiplierVsEngSpeedRatio="l9"  engSpeedRatioUnit="speed-ratio" 
engTorqueUnit="Q-Multiplier"> 

<Pair  engSpeedRatio="l.95"  engTorque="o"  /> 

<Pair  engSpeedRatio="l.9"  engTorque=".l"  /> 

<Pair  engSpeedRatio="l.82"  engTorque=".2"  /> 

<Pair  engSpeedRatio="l.73"  engTorque=".3"  /> 

<Pair  engSpeedRatio="l.62"  engTorque=".4"  /> 

<Pair  engSpeedRatio="l.57"  engTorque=".446"  /> 

<Pair  engSpeedRatio="l.5l"  engTorque=".5"  /> 

<Pair  engSpeedRatio="l.46"  engTorque=".548"  /> 

<Pair  engSpeedRatio="l.46"  engTorque=".55"  /> 

<Pair  engSpeedRatio="l.4"  engTorque=".6"  /> 

<Pair  engSpeedRatio="l.33"  engTorque=".65"  /> 

<Pair  engSpeedRatio="l.27"  engTorque=".7"  /> 

<Pair  engSpeedRatio="l.2"  engTorque=".75"  /> 

<Pair  engSpeedRatio="l.l4"  engTorque=".8"  /> 

<Pair  engSpeedRatio="l.o6"  engTorque=".85"  /> 

<Pair  engSpeedRatio="l.02"  engTorque=".9"  /> 

<Pair  engSpeedRatio=".99"  engTorque=".92"  /> 

<Pair  engSpeedRatio=".99"  engTorque=".935"  /> 

<Pair  engSpeedRatio=".99"  engTorque=".95"  /> 

<IC0NV2Commentx![CDATA[  TARDEC,  unknown  origin]]x/IC0NV2Comment> 
</TorqueConverterMultiplierVsEngSpeedRatio> 

<TractiveForceCurves  > 

<NumGearRatiosPerTransmissionOperatingRange  value="4"> 

<Commentx !  [CDATA[  TM55-2350-255-14  '79]]  >  < / Comment> 

</NumGearRatiosPerTransmissionOperatingRange> 

<NumTransmissionOperatingRanges  value="l"  /> 

<ForceCurve> 

<TractiveForceVsSpeed  numPairsTractiveForceVsSpeed="48"  speedUnit="MPH"  tractiveForceUnit="lb"  index="l"> 
<Pair  speed="o"  tractiveForce="l5l394"  /> 

<Pair  speed='T"  tractiveForce="l37427"  /> 
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<Pair  speed="2"  tractiveForce="ll5037"  /> 
<Pair  speed="2.42"  tractiveForce="l05000"  /> 
<Pair  speed="2.77"  tractiveForce="98ooo"  /> 
<Pair  speed="3"  tractiveForce="94073"  /> 
<Pair  speed="4"  tractiveForce="7924o"  /> 
<Pair  speed="5"  tractiveForce="644l7”  /> 
<Pair  speed="5.96"  tractiveForce="5l32o"  /> 
<Pair  speed="6"  tractiveForce="5l053”  /> 
<Pair  speed="7"  tractiveForce="456o9"  /> 
<Pair  speed="8"  tractiveForce="3946l"  /> 
<Pair  speed="9"  tractiveForce="35674"  /> 
<Pair  speed="9.o6"  tractiveForce="35435"  /> 
<Pair  speed="lo"  tractiveForce="33703"  /> 
<Pair  speed="ll"  tractiveForce="3l8l8"  /> 
<Pair  speed="l2"  tractiveForce="29897"  /> 
<Pair  speed="l3"  tractiveForce="27944"  /> 
<Pair  speed="l4"  tractiveForce="25958"  /> 
<Pair  speed="l5"  tractiveForce="2394o"  /> 
<Pair  speed="l6"  tractiveForce="2l89l"  /> 
<Pair  speed="l744"  tractiveForce="20H0"  /> 
<Pair  speed="l8"  tractiveForce="l9689"  /> 
<Pair  speed="l9"  tractiveForce="l8927"  /> 
<Pair  speed="20"  tractiveForce="l8l57"  /> 
<Pair  speed="2l"  tractiveForce="l7377"  /> 
<Pair  speed="22"  tractiveForce="l6589"  /> 
<Pair  speed="23"  tractiveForce="l5795"  /> 
<Pair  speed="24"  tractiveForce="l4995"  /> 
<Pair  speed="25"  tractiveForce="l4l89"  /> 
<Pair  speed="26"  tractiveForce="l338o"  /> 
<Pair  speed="27.86"  tractiveForce="l286o"  /> 
<Pair  speed="28"  tractiveForce="l28ll"  /> 
<Pair  speed="29"  tractiveForce="l2449"  /> 
<Pair  speed="30"  tractiveForce="l2o84"  /> 
<Pair  speed="3l"  tractiveForce="ll7l5"  /> 
<Pair  speed="32"  tractiveForce="ll344"  /> 
<Pair  speed="33"  tractiveForce="  10969"  /> 
<Pair  speed="34"  tractiveForce="l0592"  /> 
<Pair  speed="35"  tractiveForce="l02l3"  /> 
<Pair  speed="36"  tractiveForce="983l"  /> 
<Pair  speed="37"  tractiveForce="9446"  /> 
<Pair  speed="38"  tractiveForce="9o6i"  /> 
<Pair  speed="39"  tractiveForce="8675"  /> 
<Pair  speed="40"  tractiveForce="8287"  /> 


ERDC  TR-07-4  207 


SCAAN]]>< /IPOWERPreComment> 
speed]]  >  < /IPOWERPreComment> 

56o82]]>< /IPOWERPreComment> 
32927]]  >  < /IPOWERPreComment> 
22772]]  >  < /IPOWERPreComment> 
17869]]  >  < /IPOWERPreComment> 
13941]]  >  < /IPOWERPreComment> 
12050]]  >  < /IPOWERPreComment> 
10198]]  >  < /IPOWERPreComment> 
829l]]x/IPOWERPreComment> 


<Pair  speed="4i"  tractiveForce="7902"  /> 

<Pair  speed="4i.24"  tractiveForce="78io"  /> 

<Pair  speed="4l.35"  tractiveForce="6599"  /> 

<IPOWERPreCommentx![CDATA[  XBRCOF=  1.19  !  Based  on  max  tractive  force  at  stall]] ></IPOWERPreComment> 
<IPOWERPreCommentx![CDATA[  TF  computed  from  APG  measured  field  data  from  O-13.7  MPH.  Allison 

<IPOWERPreCommentx![CDATA[  data  from  Charles  Raffa,  TACOM  was  used  from  14.5  MPH  TO  MAX 

<IPOWERPreCommentx![CDATA[  of  vehicle.  16  I50ct'93  OKby  RBA]]x/IPOWERPreComment> 
<IPOWERPreCommentx![CDATA[  IPOWER=  42,]]x/IPOWERPreComment> 

<IPOWERPreCommentx![CDATA[  POWER=  0.0  85000  1.2  75190  2.570695  3.7  62826  5.0 

<IPOWERPreCommentx![CDATA[  6.2  49338  7.5  43718  8.7  38772  9.9  35849  11.2 

<IPOWERPreCommentx![CDATA[  12.4  31353  13.7  29105  14.5  25772  15.0  24781  16.0 

<IPOWERPreCommentx![CDATA[  17.0  20734  18.0  20149  19.0  19396  20.0  18636  21.0 

<IPOWERPreCommentx![CDATA[  22.0  17094  23.0  16313  24.0  15528  25.0  14738  26.0 

<IPOWERPreCommentx![CDATA[  27.0  13139  28.0  13131  29.0  12774  30.0  12414  31.0 

<IPOWERPreComment> < !  [CDATA[  32.0  11685  33-0  11316  34.0  10945  35. 0  10573  36.0 

<IPOWERPreCommentx![CDATA[  37.0  9821  38.0  9441  39. o  9059  40.0  8675  41.0 

<IPOWERPreCommentx![CDATA[  41.5  6825  41.6  6300]]x/IPOWERPreComment> 
<IPOWERPreCommentx !  [CDATA[  Allison  SCAAN  jan  16  '91]]  >  < /IPOWERPreComment> 

< /TractiveForceVsSpeed> 

<TransmissionGearRatiosAndEfficiencies  numPairsTransmissionGearRatiosAndEfficiencies="4"  index="  1  "> 

<Pair  gearRatio="5.88"  efficiency=".93"  /> 

<Pair  gearRatio="3.04"  efficiency=".94"  /> 

<Pair  gearRatio="i.9"  efficiency=".94"  /> 

<Pair  gearRatio="i.28"  efficiency=".95"  /> 

<PreCommentx![CDATA[  TRANS(l,l,l)  =  5.88,  0.98  !  Wes,  unknown  origin]] ></PreComment> 
<PreCommentx![CDATA[  3.04, 0.98]]x/PreComment> 

< PreComment x![CDATA[  1.90,  0.98]]x/PreComment> 

<PreCommentx![CDATA[  1.28,  o.98]]x/PreComment> 

< Comment x![CDATA[  TM55-2350-255-14  '79]]></Comment> 

</TransmissionGearRatiosAndEfficiencies> 

</ForceCurve> 


<  /T  ractiveF  orceCurves  > 


<TransmissionScenario  > 
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<Scenario  index="l"  value="l"  /> 

<Scenario  index="2"  value="l"  /> 

<Scenario  index="3"  value="l"  /> 

<Scenario  index="4"  value="l"  /> 

<Scenario  index="5"  value="l"  /> 

<Scenario  index="6"  value="l"  /> 

<Scenario  index="7”  value="l"  /> 

<Scenario  index="8"  value="l"  /> 

<Commentx![CDATA[  Sh,  P&S,  T-snd,  T-oth,  T-sno,  A-snd,  A-oth,  A-sno]]x/Comment> 

< /TransmissionScenario> 

<CentralTireInflationScenario> 

<Scenario  index="l"  value="o"  /> 

<Scenario  index="2"  value="o"  /> 

<Scenario  index="3"  value="o"  /> 

<Scenario  index="4"  value="o"  /> 

<Scenario  index="5"  value="o"  /> 

<Scenario  index="6"  value="o"  /> 

<Scenario  index="7"  value="o"  /> 

<Scenario  index="8"  value="o"  /> 

< Comment > < ! [CDATA[  N/A]]x/Comment> 

<  /  CentralTirelnflationScenario  > 

< /TransmissionInformation> 

<ObstacleDeflectionInformation> 

<AbsorbedRidePower  unitlnfo="watts"> 

<Value>6</Value> 

<Value>9</Value> 

<Value>i2</Value> 

< /AbsorbedRidePower> 

<NumRideToleranceLevel  value="l"> 

<PreCommentx![CDATA[  IPOWER=  30  !  Adjusted  (for  FDR)  data  from  WES  XMl  curve]] ></PreComment> 

< PreComment x![CDATA[  POWER=  o  135432  .9  128047  1.8  116747  2.3  110314  2.8  96875]] ></PreComment> 

< PreComment x ! [CDATA[  3.7  88240  4.6  77435  5.5  68747  6.4  51370  7.4  48166]] ></PreComment> 

<PreCommentx![CDATA[  9.2  40672  11.  33206  12.9  33205  13.8  27368  14.7  25549]]x/PreComment> 

<PreCommentx![CDATA[  16.6  25250  18.4  22535  20.3  20852  22.1  19820  23.  17057]] ></PreComment> 

<PreCommentx![CDATA[  24.9  15668  25.8  14969  26.7  13980  30.4  12725  32.2  12090]] ></PreComment> 

< PreComment x ! [CDATA[  35.4  10965  36.8  10477  38-7  9824  39.6  9495  41.5  8834]]x/PreComment> 

<PreCommentx![CDATA[  Ride  dynamics  data  for  M1E1  (M1A1)  (Driver's  position  per  R.A  l2NOV'93)]]x/PreComment> 
<PreCommentx![CDATA[  Digitized  from  plots  from  MSD  testing  group  of  APG-1984  data  loNov'93]]x/PreComment> 

< /NumRideToleranceLevel> 

<NumTireInflationDeflectionCase  value="o"> 

< Comment > < ! [CDATA[  N/A]]x/Comment> 

< /NumTireInflationDeflectionCase> 

<TireDeflectionIndex  value="o"> 
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< Comment > < ! [CDATA[  N/A]]x/Comment> 

< /TireDeflectionIndex> 

<MaxTireSpeedForTireDeflectionScenario> 

<Value>o</V  alue  > 

</MaxTireSpeedForTireDeflectionScenario> 

<ObstacleParametersByTireDeflectionIndex  numPairs="l"> 

<Pair  indexObstacleHeightVsSpeed="l"  indexRideToleranceVsSpeed="l"  /> 

<KVRCommentx![CDATA[  Sh,  P&S,  T-snd,  T-oth,  T-sno,  A-snd,  A-oth,  A-sno]]x/KVRComment> 
</ObstacleParametersByTireDeflectionIndex> 

<ObstacleHeightVsSpeedCurveGroup  numPairsObstacleHeightVsSpeed="ll"  obstacleHeightUnit="in"  maxSpeedUnit="MPFI"> 
<ObstacleHeightVsSpeedCurve  index="l"> 

<Pair  obstacleFIeight="o"  maxSpeedForObstacleHeight="loo"  /> 

<Pair  obstacleHeight="8"  maxSpeedForObstacleHeight="loo"  /> 

<Pair  obstacleHeight="lo"  maxSpeedForObstacleHeight="loo"  /> 

<Pair  obstacleHeight="l2"  maxSpeedForObstacleHeight="loo"  /> 

<Pair  obstacleFIeight="l4"  maxSpeedForObstacleHeight="loo"  /> 

<Pair  obstacleHeight="l6"  maxSpeedForObstacleHeight="35.8"  /> 

<Pair  obstacleFIeight="l8"  maxSpeedForObstacleFIeight="33.5"  /> 

<Pair  obstacleFIeight="2o"  maxSpeedForObstacleFIeight="ll.9"  /> 

<Pair  obstacleFIeight="22"  maxSpeedForObstacleHeight="7-l"  /> 

<Pair  obstacleFIeight="24"  maxSpeedForObstacleHeight="5.l"  /> 

<Pair  obstacleFIeight="6o"  maxSpeedForObstacleHeight="5.l"  /> 

<NFIVALSPreCommentx !  [CDATA[  9-watts]]  >  < /NHVALSPreComment> 

<NHVALSPreCommentx![CDATA[VRIDE(l,l,2)=  0.0  0.0  0.0  0.0  o.o]]x/NFIVALSPreComment> 
<NHVALSPreCommentx![CDATA[  0.0  0.0  0.0  0.0  o.o]]x/NHVALSPreComment> 

<NHVALSPreCommentx![CDATA[  0.0  0.0  0.0  0.0  o.o]]x/NHVALSPreComment> 

<NHVALSPreCommentx![CDATA[  0.0  o.o]]x/NHVALSPreComment> 

<NHVALSPreCommentx![CDATA[  !  12-watts]] ></NHVALSPreComment> 

<NHVALSPreCommentx![CDATA[  VRIDE(l,l,3)=  0.0  0.0  0.0  0.0  0.0  o.o]]x/NHVALSPreComment> 
<NHVALSPreCommentx![CDATA[  0.0  0.0  0.0  0.0  0.0  o.o]]x/NHVALSPreComment> 

<NHVALSPreCommentx![CDATA[  0.0  0.0  0.0  0.0  o.o]]x/NHVALSPreComment> 

<NHVALSPreCommentx !  [CDATA[  0.0  o.o]]x/NHVALSPreComment> 

<NHVALSPreCommentx !  [CDATA[  Obstacle  height-speed  2.5G  level]]  >  < /NHVALSPreComment> 

<NHVALSPreCommentx![CDATA[  Taken  from  MSD  plot  (no  identification)  loNov'93  RBA-GL]]x/NFIVALSPreComment> 
< /ObstacleFIeighfVrsSpeedCurve> 

<  /  ObstacleFIeighfVrsSpeedCurveGroup> 

<SurfaceRoughnessVsSpeedCurveGroup  numPairsSurfaceRoughnessVsSpeed="6"  surfaceRoughnessUnit="RMS-in"  maxSpeedUnit="MPH"> 
<SurfaceRoughnessVsSpeedCurve  indexl="l"  index2=”l"> 

<Pair  surfaceRoughness="o"  maxSpeedForSurfaceRoughness="loo"  /> 

<Pair  surfaceRoughness="l.32"  maxSpeedForSurfaceRoughness="loo"  /> 

<Pair  surfaceRoughness="l.83"  maxSpeedForSurfaceRoughness="26"  /> 

<Pair  surfaceRoughness="2.l3"  maxSpeedForSurfaceRoughness="l3.l"  /> 

<Pair  surfaceRoughness="3.l7"  maxSpeedForSurfaceRoughness="ll.2"  /> 
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<Pair  surfaceRoughness="5"  maxSpeedForSurfaceRoughness="ll.2"  /> 

<VRIDEPreComment>  < !  [CDATA[  6-watts]]  >  < /VRIDEPreComment> 

< /SurfaceRoughnessVsSpeedCurve> 

</SurfaceRoughnessVsSpeedCurveGroup> 

< /ObstacleDeflectionInformation> 

< /Configuration> 

<Assembly  isAssemblyPowered="true"  isAssemblyTowed="false"  isAssemblyBrakeAvailable="true"> 

<ASMCommentx![CDATA[  This  is  a  tracked  vehicle]] ></ASMComment> 

<ASMPwrPreCommentx![CDATA[  IAPG  =  l,  n/u,  NRMM-II]]x/ASMPwrPreComment> 

<MinGroundClearancePerAssemhly  value="i7"  unitlnfo="in"> 

< PreComment x![CDATA[  (Ground  clearance  =  19m  @  ctr  of  hull,  17m  min.  elsewhere,  PM  ofc  l99l)]]x/PreComment> 
< PreComment x![CDATA[  CLRMIN(l)=  18  !  TM55-2350-255-14 '79]]x/PreComment> 

<Commentx![CDATA[  JANE'S  1990-91  &  PM  ofc  l99l]]x/Comment> 

</MinGroundClearancePerAssembly> 

<ChassisToAxle  value="o"  unitlnfo="in"> 

<PreCommentx![CDATA[  >>  defeated  for  WARSIM  project  <<]]x/PreComment> 

<Commentx !  [CDATA[  to  be  derived  from  VEHDYN  data]]  >  < / Comment> 

< /ChassisToAxle> 

<HardSurfaceMotionResistance  value="o"  unitInfo="lb"  /> 

<AvgSuspensionStiffness  value="40.4"  unitlnfo="lb/in"> 

< Comment x![CDATA[  assumes  roll  center  is  C-G;  GCH-RW(l)  =  56.0-l5.6]]x/Comment> 

< /AvgSuspensionStiffness> 

<FineGrainSoilVehicleConeIndex  value="o"  /> 

<CenterToCenterTreadWidth  value="ll2"  unitlnfo="in"> 

<PreCommentx![CDATA[  WI  =  87  !  n/u,  NRMM  II;  NRMM-mgr  M1A2  Jul’93]]x/PreComment> 

< Comment x![CDATA[  TM55-2350-255-14  '79]]x/Comment> 

< /CenterToCenterTreadWidth> 

<AssemblyWeight  value="l2745l"  unitlnfo="lb"> 

<  PreComment  x![CDATA[  WGHT(l)=l26ooo  !  JANE'S  1990-91  &  PM  ofc,  l99l]]x/PreComment> 

< Comment x![CDATA[  PM  ofc,  l993]]x/Comment> 

< /AssemblyWeight> 

<MinAssemblyWidth  value="87"  unitlnfo="in"> 

< Comment x![CDATA[  TM55-2350-255-14  '79]]x/Comment> 

< /MinAssemblyWidth> 

<WheelRevPerDistance  value="768"  unitInfo="rev/Mi"> 

<PreCommentx![CDATA[  REVM(l)=  750.3  !  TARDEC,  unknown  origin]]x/PreComment> 

< Comment x![CDATA[  (lit,  7.5m  pitch)]]  x/Comment> 

< /WheelRevPerDistance> 

<TrackSetAssembly  isTrackFlexible="true"  doesTrackHavePad="true"> 

<TRKFlexCommentx !  [CDATA[  o=Girderized,  l=Flexible]]  >  < /TRKFlexComment> 

<TRKPadCommentx![CDATA[  o=None,  l=Has  Pads]]x/TRKPadComment> 

<TrackShoeArea  value="l87.5"  unitInfo="inA2"> 

<PreCommentx![CDATA[  ASHOE  =  194. o  !  Old  WES  number,  unknown  origin]] ></PreComment> 
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< PreComment >  < !  [CDATA[  ASHOE  =  189.0  !  TARDEC,  UNKNOWN  ORIGIN]]  ></PreComment> 

<Commentx![CDATA[  PITCH=7.5  WIDTH=25  25*7.5=187.5  Measured  by  RBA.  l5Nov93]]x/Comment> 

< /TrackShoeArea> 

<TrackGrouserHeight  value="i.86"  unitInfo="in"> 

< PreComment x![CDATA[  GROUSH(l)=  1.55  !  WES,  unknown  origin]] ></PreComment> 

<Commentx![CDATA[  T-178  track  Drwing#  12348368  ’93]]x/Comment> 

< /TrackGrouserHeight> 

<NumTrackRoadWheel  value="l4"> 

<Commentx !  [CDATA[  TM55-2350-255-14  '79]]  >  < / Comment> 

< /NumTrackRoadWheel> 

<TrackBogieEffectiveRadius  value="l5.6"  unitlnfo="in"> 

< Comment x![CDATA[  WES,  TM55-2350-255-14  '79]]x/Comment> 

< /TrackBogieEffectiveRadius  > 

<TrackGroundLength  value="l8o"  unitInfo="in"> 

<PreCommentx![CDATA[  TRAKLN(l)=l83.l  !  WES,  unknown  origin]] ></PreComment> 

<  PreComment  x![CDATA[  TRAKLN(l)=l8o.o8  !  FSP83-025,  Apr'83]]x/PreComment> 

< Comment x![CDATA[  TM55-2350-255-14  '79]]></Comment> 

< /TrackGroundLength> 

<TrackWidth  value="25"  unitInfo="in'’> 

< Comment x![CDATA[  NRMM-mgr  M1A2  Jul'93,  Measured  by  RBA.  l5Nov'93]]x/Comment> 

</TrackWidth> 

< /TrackSetAssembly> 

</Assembly> 

<VehicleObstacleData  numObstacleAngles="8"  numObstacleHeights="4"  numObstacleWidths="3"  minClearanceUnit="in"  maxForceUnit=''lb"  avgForceUnit="lb" 
obstacleHeightUnit="in"  obstacleAngleUnit="rad"  obstacleWidthUnit="in"> 

<ObstaclePoint  minClearance="l4.05"  maxForceOverride="lo852.9"  avgForceOverride="64l"  obstacleHeight="3.l5"  obstacleAngle="l.95"  obstacleWidth="5.88" 

/> 

<ObstaclePoint  minClearance="5.76"  maxForceOverride="28l46.7"  avgForceOverride="l702.6"  obstacleFJeight="l5.75"  obstacleAngle="l.95" 
obstacleWidth="5.88"  /> 

<ObstaclePoint  minClearance="3.83"  maxForceOverride="536o6.l"  avgForceOverride="2449.l"  obstacleHeight="3346"  obstacleAngle="l.95" 
obstacleWidth="5.88"  /> 

<ObstaclePoint  minClearance="3.48"  maxForce0verride="73O32.2"  avgForceOverride="l255llo"  obstacleFIeight= "45.46"  obstacleAngle="l.95" 
obstacleWidth="5.88"  /> 

<ObstaclePoint  minClearance="l4.05"  maxForceOverride="lo870.8"  avgForceOverride="68o"  obstacleHeight="3.l5"  obstacleAngle="2.48"  obstacleWidth="5.88" 

/> 

<ObstaclePoint  minClearance="5.75"  maxForceOverride="24l48.l"  avgForceOverride="l538"  obstacleHeight="l5.75"  obstacleAngle="2.48"  obstacleWidth="5.88" 

/> 

<ObstaclePoint  minClearance="3.89"  maxForceOverride="52966.7"  avgForceOverride="3385.3"  obstacleFIeight="33.46"  obstacleAngle="2.48" 
obstacleWidth="5.88"  /> 

<ObstaclePoint  minClearance="3.67"  maxForceOverride="73l72.5"  avgForceOverride="l4l8805"  obstacleFIeight="45.46"  obstacleAngle="2.48" 
obstacleWidth="5.88"  /> 

<ObstaclePoint  minClearance="l4"  maxForceOverride="lo888.3"  avgForceOverride="687.5"  obstacleFIeight="3.l5"  obstacleAngle="2.69"  obstacleWidth="5.88" 
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/> 

obstacleWidth= 

obstacleWidth= 

/> 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

/> 

/> 

obstacleWidth= 

obstacleWidth= 

/> 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

/> 

/> 

/> 

/> 


•cObstaclePoint  minClearance= 

<ObstaclePoint  minClearance= 
'5-88"  /> 

<ObstaclePoint  minClearance= 
'5-88"  /> 

•cObstaclePoint  minClearance= 

<ObstaclePoint  minClearance= 
'5-88"  /> 

•cObstaclePoint  minClearance= 
'5-88"  /> 

•cObstaclePoint  minClearance= 
'5-88"  /> 

<ObstaclePoint  minClearance= 

<ObstaclePoint  minClearance= 

<ObstaclePoint  minClearance= 
'5-88"  /> 

<ObstaclePoint  minClearance= 
'5.88"  /> 

<ObstaclePoint  minClearance= 

<ObstaclePoint  minClearance= 
'5.88"  /> 

<ObstaclePoint  minClearance= 
'5.88"  /> 

<ObstaclePoint  minClearance= 
'5.88"  /> 

<ObstaclePoint  minClearance= 

<ObstaclePoint  minClearance= 
'5-88"  /> 

<ObstaclePoint  minClearance= 

<ObstaclePoint  minClearance= 

<ObstaclePoint  minClearance= 

<ObstaclePoint  minClearance= 

<ObstaclePoint  minClearance=' 


'5.8"  maxForceOverride="30034.5"  avgForceOverride="l596"  obstacleFIeight="l5.75"  obstacleAngle="2.69"  obstacleWidth="5.88" 

'4.19"  maxForceOverride="4l87l.7"  avgForceOverride="3302.3"  obstacleFIeight="33.46"  obstacleAngle="2.69" 

'4.23"  maxForceOverride="44250.6"  avgForceOverride="l383338"  obstacleFleight="45.46"  obstacleAngle="2.69" 

'14.02"  maxForceOverride="9978"  avgForceOverride="7l2.2"  obstacleFIeight="3.l5"  obstacleAngle="2.86"  obstacleWidth="5.88" 

'6.4"  maxForceOverride="2l738.5"  avgForceOverride="l5o8.2"  obstacleHeight="l5.75"  obstacleAngle="2.86" 

'5.4"  maxForceOverride="27268.3"  avgForceOverride="28l3.3"  obstacleHeight="33.46"  obstacleAngle="2.86" 

'5.42"  maxForceOverride="34730.3"  avgForceOverride^'3829.5"  obstacleHeight= "45.46"  obstacleAngle="2.86" 

'16.24"  maxForceOverride="59lo.7"  avgForceOverride="277.9"  obstacleFleight="3.l5"  obstacleAngle="342"  obstacleWidth="5.88" 

'9.31"  maxForceOverride="9950"  avgForceOverride="l346.9"  obstacleHeight="l5.75"  obstacleAngle="342"  obstacleWidth="5.88" 

'8.94"  maxForceOverride="22438.3"  avgForceOverride="236o"  obstacleHeight="3346"  obstacleAngle="342" 

'7.81"  maxForceOverride^'28948.7"  avgForceOverride="3534"  obstacleHeight="4546"  obstacleAngle="342" 

'16.64"  maxForceOverride="5400.3"  avgForceOverride="88.3"  obstacleHeight="3.l5"  obstacleAngle="3.6"  obstacleWidth="5.88" 

'11.13"  maxForceOverride="l67954"  avgForceOverride="2o83.7”  obstacleFleight="l5.75"  obstacleAngle="3.6" 

'543"  maxForceOverride="l9l66.7"  avgForceOverride="l058.8"  obstacleHeight="3346"  obstacleAngle="3.6" 

'2.6"  maxForceOverride="48223.8"  avgForceOverride="3287.5"  obstacleHeight="4546"  obstacleAngle="3.6" 

'17"  maxForceOverride="3279.l"  avgForceOverride="754"  obstacleHeight="3.l5"  obstacleAngle="3.8"  obstacleWidth="5.88"  /> 
'14.86"  maxForceOverride="ll345.6"  avgForceOverride="l202.9"  obstacleFIeight="l5.75"  obstacleAngle="3.8" 

'5"  maxForceOverride="265l8.3"  avgForceOverride="2540.5"  obstacleFIeight="33.46"  obstacleAngle="3.8"  obstacleWidth="5.88" 

'5.61"  maxForce0verride="2l3O4"  avgForceOverride="5ll.6"  obstacleFIeight= "45.46”  obstacleAngle="3.8"  obstacleWidth="5.88" 

'17"  maxForceOverride="l4794"  avgForceOverride=".3"  obstacleHeight="3.l5"  obstacleAngle="4.33"  obstacleWidth="5.88"  /> 
'16.65"  maxForceOverride="3699.2"  avgForceOverride="45.6"  obstacleHeight="l5.75"  obstacleAngle="4.33"  obstacleWidth="5.88" 

'tS-QS"  maxForceOverride="82l5"  avgForceOverride="270.3"  obstacleHeight="3346”  obstacleAngle="4.33"  obstacleWidth="5.88" 
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/> 

/> 

/> 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

/> 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

/> 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 


<ObstaclePoint  minClearance="l5.l6"  maxForceOverride="l2l95"  avgForceOverride="959.3"  obstacleHeight="45.46"  obstacleAngle="4.33"  obstacleWidth="5.88" 

<ObstaclePoint  minClearance="l4.32"  maxForceOverride="47l8.6"  avgForceOverride="266.l"  obstacleHeight="3.l5"  obstacleAngle="l.95"  obstacleWidth="29.88" 

<ObstaclePoint  minClearance="8.33"  maxForceOverride="l3034"  avgForceOverride="902.4"  obstacleHeight="l5.75"  obstacleAngle="l.95"  obstacleWidth="29.88" 

<ObstaclePoint  minClearance="4.l4"  maxForceOverride="272l8.l"  avgForceOverride="2392.2"  obstacleHeight="3346"  obstacleAngle="l.95" 

'29.88"  /> 

<ObstaclePoint  minClearance="3.89"  maxForceOverride="7ll2l.3"  avgForceOverride="962383.9"  obstacleHeight="4546"  obstacleAngle="l.95" 

'29.88"  /> 

<ObstaclePoint  minClearance="l4.32"  maxForceOverride="47l8.6"  avgForceOverride="282.2"  obstacleHeight="3.l5"  obstacleAngle="2.48" 

'29.88"  /> 

•cObstaclePoint  minClearance="8.55"  maxForceOverride="l9073.8"  avgForceOverride="l368"  obstacleHeight="l5.75"  obstacleAngle="2.48" 

'29.88"  /> 

<ObstaclePoint  minClearance="6.49"  maxForceOverride="47583.9"  avgForceOverride="l55925.9"  obstacleHeight="3346"  obstacleAngle="2.48" 

'29.88"  /> 

•cObstaclePoint  minClearance="4.62"  maxForceOverride="53589.7"  avgForceOverride^'3748.4"  obstacleHeight="4546"  obstacleAngle="2.48" 

'29.88"  /> 

•cObstaclePoint  minClearance="l4.32"  maxForceOverride="47l8.6"  avgForce0verride="282"  obstacleHeight="3.l5"  obstacleAngle="2.69"  obstacleWidth="29.88" 

<ObstaclePoint  minClearance="8.37"  maxForceOverride="l272l.6"  avgForceOverride="l424.8"  obstacleHeight="l5.75"  obstacleAngle="2.69" 

'29.88"  /> 

<ObstaclePoint  minClearance="5.89"  maxForceOverride="4l3lo"  avgForceOverride="2982.3"  obstacleHeight="3346"  obstacleAngle="2.69" 

'29.88"  /> 

<ObstaclePoint  minClearance="5.86"  maxForceOverride="44838.6"  avgForceOverride="292235.8"  obstacleHeight="4546"  obstacleAngle="2.69" 

'29.88"  /> 

<ObstaclePoint  minClearance="l4.29"  maxForceOverride="7977.l"  avgForceOverride="387"  obstacleHeight="3.l5"  obstacleAngle="2.86"  obstacleWidth="29.88" 

<ObstaclePoint  minClearance="8.62"  maxForceOverride="l3o84"  avgForceOverride="l36o.l"  obstacleHeight="l5.75"  obstacleAngle="2.86" 

'29.88"  /> 

•cObstaclePoint  minClearance="7.6l"  maxForceOverride="25537.8"  avgForceOverride="29o6.7"  obstacleHeight="3346"  obstacleAngle="2.86" 

'29.88"  /> 

<ObstaclePoint  minClearance="7.65"  maxForce0verride="289O3.2"  avgForceOverride="3877.l"  obstacleHeight="4546"  obstacleAngle="2.86" 

'29.88"  /> 

<ObstaclePoint  minClearance="l5.l6"  maxForceOverride="9945.6"  avgForceOverride="840.8"  obstacleHeight="3.l5"  obstacleAngle="342" 

'29.88"  /> 

<ObstaclePoint  minClearance="8.76"  maxForceOverride="9938.8"  avgForceOverride="98l.8"  obstacleHeight="l5.75"  obstacleAngle="342" 

'29.88"  /> 

<ObstaclePoint  minClearance="9"  maxForceOverride^'25434.3"  avgForceOverride="2926.3"  obstacleHeight="3346"  obstacleAngle="342" 

'29.88"  /> 

•cObstaclePoint  minClearance="7.97"  maxForceOverride="28955.3"  avgForceOverride="36l0.3"  obstacleHeight="4546"  obstacleAngle="342" 

'29.88"  /> 
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/> 

obstacleWidth= 

obstacleWidth= 

/> 

/> 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

/> 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 


<ObstaclePoint  minClearance="l5.l4"  maxForceOverride="ll634.5"  avgForceOverride="823.6"  obstacleHeight="3.l5"  obstacleAngle="3.6"  obstacleWidth="29.88" 

<ObstaclePoint  minClearance="7-43"  maxForceOverride="l7279.2"  avgForceOverride="2405.9"  obstacleHeight="l5.75"  obstacleAngle="3.6" 

'29.88"  /> 

<ObstaclePoint  minClearance="5.84"  maxForceOverride="47750.5"  avgForceOverride="2868.5"  obstacleHeight="3346"  obstacleAngle="3.6" 

'29.88"  /> 

<ObstaclePoint  minClearance="6.06"  maxForceOverride=".l"  avgForceOverride="-88l236.8"  obstacleHeight="4546"  obstacleAngle="3.6"  obstacleWidth="29.88" 

<ObstaclePoint  minClearance="l5.63"  maxForceOverride="9497.2"  avgForceOverride="3l6.l"  obstacleHeight="3.l5"  obstacleAngle="3.8"  obstacleWidth="29.88" 

<ObstaclePoint  minClearance="ll.24"  maxForceOverride="l9682.8"  avgForceOverride="326o"  obstacleHeight="l5.75"  obstacleAngle="3.8" 

'29.88"  /> 

•cObstaclePoint  minClearance="4.77"  maxForceOverride="253l5.3"  avgForceOverride="l82l.3"  obstacleHeight="3346"  obstacleAngle="3.8" 

'29.88"  /> 

<ObstaclePoint  minClearance="4.5l"  maxForceOverride="25782.3"  avgForceOverride="3247.l"  obstacleHeight="4546"  obstacleAngle="3.8" 

'29.88"  /> 

•cObstaclePoint  minClearance="l6.03"  maxForceOverride="9262.4"  avgForceOverride="622.2"  obstacleHeight="3.l5"  obstacleAngle="4.33" 

'29.88"  /> 

•cObstaclePoint  minClearance="l5.l6"  maxForce0verride="l22l44"  avgForceOvemde^'964.4"  obstacleFIeight="l5.75"  obstacleAngle="4.33" 

'29.88"  /> 

<ObstaclePoint  minClearance="l2.9l”  maxForceOverride^'14359.5"  avgForceOverride="l256.l"  obstacleHeight="3346"  obstacleAngle="4.33” 

'29.88"  /> 

<ObstaclePoint  minClearance="l2.26"  maxForceOverride="20448.2"  avgForceOverride="3497.3"  obstacleHeight="4546"  obstacleAngle="4.33" 

'29.88"  /> 

<ObstaclePoint  minClearance="l4.86"  maxForceOverride="l0372"  avgForceOverride="390.4"  obstacleFIeight="3.l5"  obstacleAngle="l.95"  obstacleWidth="l4l.6" 

<ObstaclePoint  minClearance="945"  maxForceOverride="20364.5"  avgForceOverride="l644.9"  obstacleHeight="l5.75"  obstacleAngle="l.95" 

'141.6"  /> 

<ObstaclePoint  minClearance="5.6l"  maxForceOverride="32498.8"  avgForceOverride="64269.5"  obstacleHeight="3346"  obstacleAngle="l.95" 

'141.6"  /> 

•cObstaclePoint  minClearance="3.88"  maxForceOverride="7l3o8"  avgForceOverride="ll23302"  obstacleHeight="4546"  obstacleAngle="l.95" 

'141.6"  /> 

•cObstaclePoint  minClearance="l4.86"  maxForce0verride="lO439.5"  avgForceOverride="409.6"  obstacleHeight="3.l5"  obstacleAngle="2.48" 

'141.6"  /> 

<ObstaclePoint  minClearance="9.64"  maxForceOverride="26o934"  avgForceOverride="l898.3"  obstacleHeight="l5.75"  obstacleAngle="2.48" 

'141.6"  /> 

•cObstaclePoint  minClearance="5.8"  maxForceOverride="475ll.3"  avgForceOverride="3604.7"  obstacleHeight="3346"  obstacleAngle="2.48" 

'141.6"  /> 

<ObstaclePoint  minClearance="5.l3"  maxForceOverride="6l869.7”  avgForceOverride="456o.9"  obstacleHeight= "45.46"  obstacleAngle="2.48" 

'141.6"  /> 

<ObstaclePoint  minClearance="l4.86"  maxForceOverride="l037l.9"  avgForceOverride="4o8.l"  obstacleHeight="3.l5"  obstacleAngle="2.69" 

'141.6"  /> 
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obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

/> 

obstacleWidth= 

obstacleWidth= 

obstacleWidth= 

/> 

/> 

obstacleWidth= 

obstacleWidth= 

/> 

obstacleWidth= 

obstacleWidth= 

/> 

obstacleWidth= 

obstacleWidth= 


<ObstaclePoint  minClearance= 
'141.6"  /> 

<ObstaclePoint  minClearance= 
'141.6"  /> 

<ObstaclePoint  minClearance= 
'141.6”  /> 

<ObstaclePoint  minClearance= 
'141.6"  /> 

<ObstaclePoint  minClearance= 
'141.6"  /> 

<ObstaclePoint  minClearance= 
'141.6"  /> 

<ObstaclePoint  minClearance= 
'141.6"  /> 

<ObstaclePoint  minClearance= 

<ObstaclePoint  minClearance= 
'141.6"  /> 

<ObstaclePoint  minClearance= 
'141.6"  /> 

<ObstaclePoint  minClearance= 
'141.6"  /> 

<ObstaclePoint  minClearance= 

<ObstaclePoint  minClearance= 

<ObstaclePoint  minClearance= 
'141.6"  /> 

<ObstaclePoint  minClearance= 
'141.6"  /> 

<ObstaclePoint  minClearance= 

<ObstaclePoint  minClearance= 
'141.6"  /> 

<ObstaclePoint  minClearance= 
'141.6"  /> 

<ObstaclePoint  minClearance= 

<ObstaclePoint  minClearance= 
'141.6"  /> 

<ObstaclePoint  minClearance= 
'141.6"  /> 


'10.05"  maxForceOverride="l7224 .7"  avgForceOverride="l645.3"  obstacleHeight="l5.75"  obstacleAngle="2.69" 

'6.62"  maxForceOverride="477l4.9"  avgForceOverride="27l3.8"  obstacleHeight="3346"  obstacleAngle="2.69" 

'5.49"  maxForceOverride="47584.3"  avgForceOverride="389l"  obstacleHeight="4546"  obstacleAngle="2.69" 

'14.94"  maxForceOverride="99l8.9"  avgForceOverride="486.4"  obstacleHeight="3.l5"  obstacleAngle="2.86" 

'10.87"  maxForceOverride="l273l.6"  avgForceOverride="l739.8"  obstacleHeight="l5.75"  obstacleAngle="2.86" 

'8.99"  maxForceOverride="25467.9"  avgForceOverride="3l8l.4"  obstacleHeight="3346"  obstacleAngle="2.86" 

'8.91"  maxForceOverride="28949.9"  avgForceOverride="38634"  obstacleHeight="4546"  obstacleAngle="2.86" 

'14.95"  maxForceOverride="9949.8"  avgForceOverride=”537.3"  obstacleHeight="3.l5"  obstacleAngle="342"  obstacleWidth="l4l.6" 
'10.87"  maxForceOverride="l234l.7"  avgForceOverride="l923.5"  obstacleHeight="l5.75"  obstacleAngle="342" 

'8.92"  maxForceOverride="24274.5"  avgForceOverride="3320.9"  obstacleHeight="3346"  obstacleAngle="342" 

'8.92"  maxForceOverride="28955"  avgForceOverride="4l53.9"  obstacleHeight="4546"  obstacleAngle="342" 

'14.81"  maxForceOverride="ll65l.7"  avgForceOverride="662.2"  obstacleHeight="3.l5"  obstacleAngle="3.6"  obstacleWidth="l4l.6" 
'lo"  maxForceOverride="l7482.4"  avgForceOverride="2555.9"  obstacleHeight="l5.75"  obstacleAngle="3.6"  obstacleWidth="l4l.6" 
'5.99"  maxForceOverride="4749l.3"  avgForceOverride="3382.6”  obstacleHeight="3346"  obstacleAngle="3.6" 

'4.72"  maxForceOverride="47llo.l"  avgForceOverride="4367.l"  obstacleHeight="4546"  obstacleAngle="3.6" 

'14.81"  maxForceOverride="84ll.7"  avgForceOverride="400.2"  obstacleHeight="3.l5"  obstacleAngle="3.8"  obstacleWidth="l4l.6" 
'8.89"  maxForceOverride="262l8.4"  avgForceOverride="20o6.4"  obstacleHeight="l5.75"  obstacleAngle="3.8" 

'-5.19"  maxForceOverride="37355.7"  avgForceOverride="3593.5"  obstacleHeight="3346"  obstacleAngle="3.8" 

'4.99"  maxForceOverride=".l"  avgForceOverride="-89379.3"  obstacleHeight="4546"  obstacleAngle="3.8"  obstacleWidth=''l4l.6" 
'14.84"  maxForceOverride="ll094.6"  avgForceOverride="433.5"  obstacleHeight="3.l5"  obstacleAngle="4.33" 

'9.41"  maxForceOverride="24920.l"  avgForceOverride="387l.2"  obstacleHeight="l5.75"  obstacleAngle="4.33" 
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<ObstaclePoint  minClearance="-l0.66"  maxForceOverride="42o87.8"  avgForceOverride="7l63.7"  obstacleFIeight="33.46"  obstacleAngle="4.33" 
obstacleWidth="l4l.6"  /> 

<ObstaclePoint  minClearance="6.l6"  maxForceOverride=".l"  avgForceOverride="-l95667"  obstacleHeight="4546"  obstacleAngle="4.33"  obstacleWidth="l4l.6" 


/> 


< /VehicleObstacleData> 
</Vehicle> 
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APPENDIX  H:  M-COP  THREAT  ANALYSIS 
CATEGORY 


Table  HI.  Threat  Analysis  class:  TH REAT_COU RSE_OF_ACTION .* 


Attribute 

Definition 

Cardinality 

Data  Type 

Units  of  Measure  /  other  notes 

Course_Of_Acti 

on_Name 

Identifier  for  the  THREAT_COURSE_OF_ACTION. 

1 

string 

There  are  usually  3  or  more 
developed  courses  of  action 
(COAs)  for  consideration. 

Threat_Unit_ 

Name 

Name  of  the  unit  associated  with  the 

THREAT_COURSE_OF_ACTION. 

1 

string 

Threat_Unit_ 

Objective_Loca 

tion 

Location  (x,y,z)  of  the  assumed  objective  for  the 

threat  unit. 

float 

Also  known  as  the  "Why". 

Threat_Unit_ 

What 

"...the  type  of  operation,  such  as  attack,  defend, 
reinforce,  or  conduct  retrograde."  -  FM  34-130 

1 

string 

Threat_Unit_ 

When 

"...the  time  the  action  will  begin."  -  FM  34-130 

1 

float 

Threat_Unit_ 

Where 

"...the  sectors,  zones,  axis  of  attack,  avenues  of 
approach,  and  objectives  that  makes  up  the  COA."  - 

FM  34-130 

>1 

string 

*  “A  possible  plan  open  to  an  individual  or  commander  that  would  accomplish  or  is  related  to  accomplishment  of  the 
mission.  A  COA  is  initially  stated  in  broad  terms  with  the  details  determined  during  staff  wargaming.  To  develop  COAs,  the 
staff  must  focus  on  key  information  and  intelligence  necessary  to  make  decisions.  COAs  include  five  elements:  WHAT 
(the  type  of  operation),  WHEN  (the  time  the  action  will  begin),  WHERE  (boundaries,  axis,  etc.),  HOW  (the  use  of  assets), 
and  WHY  (the  purpose  or  desired  end  state).”  -  FM  34-130  (HQDA  1994). 
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Table  H2.  Threat  Analysis  class:  SITUATION_TEMPLATE.* 


Attribute 

Definition 

Cardinality 

Data 

Type 

Units  of  Measure  /  other 

notes 

Unit_Type 

Type  of  unit  being  assessed. 

1 

string 

Unit_Name 

Name  of  unit. 

1 

string 

Unit_Locations 

Location  of  the  unit  within  the  battlespace  area  of 

interest. 

1 

float 

Time_Phase_Line_H 

See  Appendix  D. 

1... 

N 

float 

Class  in  Maneuver 

Analysis  category. 

H  i  gh_Va  1  u  e_T  a  rget 
_X_Location 

Location  of  the  particular  high  value  target. 

>  = 

1 

float 

*  "A  depiction  of  assumed  adversary  dispositions,  based  on  adversary  doctrine  and  the  effects  of  the 
battlespace  if  the  adversary  should  adopt  a  particular  course  of  action.  In  effect,  situation  templates 
are  the  doctrinal  templates  depicting  a  particular  operation  modified  to  account  for  the  effects  of  the 
battlespace  environment  and  the  adversary's  current  situation  (training  and  experience  levels,  logistic 
status,  losses,  dispositions).  Normally,  the  situation  template  depicts  adversary  units  two  levels  of 
command  below  the  friendly  force,  as  well  as  the  expected  locations  of  high-value  targets.  Situation 
templates  use  time-phase  lines  to  indicate  movement  of  forces  and  the  expected  flow  of  the  operation. 
Usually,  the  situation  template  depicts  a  critical  point  in  the  course  of  action.  Situation  templates  are 
one  part  of  an  adversary  course  of  action  model.  Models  may  contain  more  than  one  situation 
template.11  (JP  2-03.1)  -  FM  3-06. 
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APPENDIX  I:  M-COP  UTILITIES  CATEGORY 


Table  II.  Utilities  category  classes  and  attributes. 


Class 

Attribute 

Enumeration 

Source 

Name 

Definition 

Name 

Definition 

Value 

Label 

DATA_ 

QUALITY 

Metadata 

describing  the 
quality  of  the 

data. 

Completeness 

Information  about 

omissions,  selection  criteria, 
generalization,  definitions 
used,  and  other  rules  used 

to  derive  the  data. 

DDMS, 

EDCS 

Existence_Certain 

ty 

The  certainty  of  existence  of 
an  object. 

1-5 

EDCS 

Existence_Status 

The  status  or  existence 
condition  of  an  object. 

1-65 

EDCS 

Florizontal_Positio 
nal_  Accuracy 

An  explanation  of  the 
accuracy  of  the  horizontal 
positions  (coordinates)  of 
spatial  objects. 

DDMS, 

EDCS 

Vertical_Positional 
_  Accuracy 

An  explanation  of  the 
accuracy  of  the  vertical 
positions  (coordinates)  of 
spatial  objects. 

DDMS, 

EDCS 

FEATURE 

Representation 

of  real  world 

features. 

Areal_Feature 

SEDRIS 

DRM 

Linear_Feature 

SEDRIS 

DRM 

Point_Feature 

SEDRIS 

DRM 

Volumetric_Featur 

e 

SEDRIS 

DRM 

FEATURE_ 

TOPOLOGY 

Topology  of  the 

real  world 

features. 

Feature_Edge 

SEDRIS 

DRM 

Edge_Direction 

SEDRIS 

DRM 

Feature_Face 

SEDRIS 

DRM 

Face_Direction 

SEDRIS 

DRM 

Feature_Node 

SEDRIS 

DRM 

Feature_Volume 

SEDRIS 

DRM 
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Class 

Attribute 

Enumeration 

Source 

Name 

Definition 

Name 

Definition 

Value 

Label 

FORMAT 

Physical 

attributes  of  the 

asset. 

Format 

The  physical  or  digital 

manifestation  of  the 

resource. 

media_format 

DDMS 

extent_qualifier 

DDMS 

extent 

DDMS 

medium 

DDMS 

Meida_Type 

Type  of  media  (i.e.,  CD, 
tape,  etc.) 

Multipl 

e 

EDCS, 

JMCDM 

GEOMETRY 

Spatial 

representation 
of  an  object. 

Arc 

SEDRIS 

DRM 

Line 

SEDRIS 

DRM 

Ellipse 

SEDRIS 

DRM 

Polygon 

SEDRIS 

DRM 

Point 

SEDRIS 

DRM 

LOCATION 

Information 

about  the 

location  of 

another  object 

relative  to  this 

object. 

Geodetic_Azimuth 

The  vector  azimuth  geodetic 
in  the  horizontal  plane  at 
the  observer’s  LOCATION,  to 
either  a  Line  passing 
through  the  observer,  or  a 

vector  relative  to  the 

observer,  or  the  direction 

from  the  observer  to  an 
object  of  LOCATION. 

EDCS 

Geodetic_Datum 

The  datum  describing  the 
relationship  of  a  coordinate 
system  to  the  earth. 

EDCS 

Geodetic_Datum_ 

Identifier 

The  designation  of  a 
Geodetic_Datum. 

1-307 

EDCS 

Geographic_ 

Information 

A  LOCATION  or  region  where 
geographic  information  or 
statistics  may  apply. 

EDCS 

FlorizontaL 

Reference_Datum 

A  frame  of  reference  for 

geodetic  latitude  and 
longitude. 

Location_Property 

_Set 

A  property  set  describing 
properties  of  a  location. 

Includes  LOCATION  name. 

EDCS 

Point_ldentifier 

The  identifier  that 

represents  a  specific 

LOCATION. 

JMCDM 
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Class 

Attribute 

Enumeration 

Source 

Name 

Definition 

Name 

Definition 

Value 

Label 

Vertical_Referenc 
e  _Datum 

The  code  that  represents  a 
Vertica  l_Ref  erence_Datu  m . 

1-46 

JMCDM, 

EDCS* 

RESOURCE 

Maintenance 

and 

administration 

information. 

Contributor 

Information  about  an 

organization,  person,  or 
entity  that  contributed 

intellectual  content  to  a 

resource,  other  than  the 
publishing  organization. 

contributor 

DDMS 

Creator 

Information  about  the  entity 
responsible  for  generating 

the  resource. 

creator 

DDMS 

Date 

A  calendar  date  associated 

with  an  event  in  the  life 
cycle  of  the  resource. 

date_created 

DDMS 

date_posted 

DDMS 

date_valid_til 

DDMS 

date_info_cut_off 

DDMS 

Identifier 

An  unambiguous  reference 
to  a  resource  within  a  given 

context. 

DDMS 

lnterest_Type 

The  reason  an  object  is  of 

interest. 

EDCS 

Keyword 

Keywords  describing  data 

set. 

JMCDM 

Language 

The  primary  language  of  the 

intellectual  content  of  the 

resource. 

language_qualifi 

er 

DDMS 

language_value 

DDMS 

Organization 

Information  about  an 

organization. 

name 

DDMS 

phone_number 

DDMS 

email_address 

DDMS 

Person 

Information  about  a  person. 

surname 

DDMS 

name 

DDMS 

user_id 

DDMS 

organization 

DDMS 

phone_number 

DDMS 

email_address 

DDMS 

Only  at  attribute  level;  not  enumerations. 
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Class 

Attribute 

Enumeration 

Source 

Name 

Definition 

Name 

Definition 

Value 

Label 

Publisher 

This  category  is  used  to  tag 

the  identification  of  the 

entity  responsible  for 
releasing  the  data  asset— 
the  entity  primarily 
responsible  for  the 
intellectual  content  of  the 

product.  It  is  intended  that 
this  category  apply 
whenever  applicable  to  an 
organization,  as  opposed  to 

a  person. 

publisher 

DDMS 

Reference_Citatio 

n 

JMCDM, 

EDCS 

Rights 

Information  about  rights 

held  in  and  over  the 

resource. 

privacy.act 

DDMS 

intellectual. 

property.rights 

DDMS 

copyright 

DDMS 

Title 

A  name,  or  names,  given  to 

the  resource. 

DDMS 

Type 

The  nature,  genre,  or 
discipline,  of  the  content  of 

the  resource. 

type_qualifier 

DDMS 

type.value 

DDMS 

Web.Service 

Information  about  a 

Web.Service. 

name 

DDMS 

phone.number 

DDMS 

email.address 

DDMS 

SECURITY. 

CLASSIFICA¬ 

TION 

The  level 

assigned  to 
national  security 

information  and 

material  that 

denotes  the 

degree  of 
damage  that  its 

unauthorized 

disclosure  would 

cause  to 

national  defense 

or  foreign 

relations  of  the 

United  States 

and  the  degree 
of  protection 
required. 

Security. 

Classification. 

Description.Text 

The  text  that  describes  a 

security  classification. 

DDMS, 

EDCS, 

JMCDM 
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Class 

Attribute 

Enumeration 

Source 

Name 

Definition 

Name 

Definition 

Value 

Label 

Security.Leve! 

The  highest  level  of  security 
associated  with  an  object. 

1-5 

DDMS, 

EDCS, 

JMCDM 

SOURCE 

References  to 

assets  or 

resources  from 

which  the 

tagged  data 

asset  is  derived. 

Source 

DDMS, 

EDCS, 

JMCDM 

Source_Data_Set 

_Compile_Date 

EDCS 

Source_Data_Set 

.Edition 

EDCS 

Source.Data.Set 

.General.lnforma 

tion 

EDCS 

Source.Data.Set 

.Name 

EDCS 

Source.Data.Set 

.Print.Date 

EDCS 

Source.Data.Set 

.Revision.Date 

EDCS 

SUMMARY. 

CONTENT 

Concepts  and 
topics 

Subject 

Subject  keyword(s)  that 
characterize  the  subject 

matter  of  a  resource. 

category_qualifie 

r 

DDMS 

category.code 

DDMS 

category.label 

DDMS 

keyword 

DDMS 

Geospatial. 
Coverage  (M-A*) 

Geographic  place  names  or 

coordinates  that  relate  to 

the  resource,  such  as  a 
jurisdiction,  point,  area,  or 
volume  on  land,  in  space,  or 

at  sea. 

geographic. 

identifier 

DDMS 

geographic. 

bounding_box 

DDMS 

geographic 

_bounding_ge- 

ometry 

DDMS 

postal.address 

DDMS 

vertical.extent 

DDMS 

facility_be_numb 

er 

DDMS 

facility.suffix 

DDMS 

region 

DDMS 

If  applicable,  an  attribute  must  be  supplied,  for  a  given  class. 
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Class 

Attribute 

Enumeration 

Source 

Name 

Definition 

Name 

Definition 

Value 

Label 

name 

DDMS 

westboundjongi 

tude 

DDMS 

eastboundjongit 

ude 

DDMS 

northbound_ 

latitude 

DDMS 

south  bound_ 

latitude 

DDMS 

street 

DDMS 

city 

DDMS 

state 

DDMS 

postal_code 

DDMS 

country_code_ 

qualifier 

DDMS 

country_code 

DDMS 

province 

DDMS 

minimum_ 

vertical_extent 

DDMS 

maximum_ 

vertical_extent 

DDMS 

Temporal_Covera 
ge  (M-A) 

Subject  matter  coverage 
expressed  in  terms  of  one 
or  more  periods  of  time. 

date_start  (M-A) 

DDMS 

date_end  (M-A) 

DDMS 

time_period  (M- 
A) 

DDMS 

Virtual_Coverage 

The  subject-matter  coverage 
of  a  publication  in  terms  of 

one  or  more  virtual 

addresses. 

virtual_address 

DDMS 

network_protocol 

DDMS 

Description 

An  account  of  the  content  of 

the  resource. 

description 

DDMS 

TIME 

Date_Format 

The  format  of  a  date. 

1-46 

calendar_date 

EDCS 

Hour_Within_Day 

The  ordinal  index  of  the 

hour  within  the  day,  starting 

with  the  number  "0"  at 

midnight. 

EDCS 

Julian_Date_ 

Terrestial_Time 

The  Julian_Day  number  for 
the  preceding  noon  plus  the 
fraction  of  the  day  since 

that  instant. 

EDCS 

Julian_Day 

The  Julian_Day  number 

associated  with  the  solar 

day. 

EDCS 
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Class 

Attribute 

Enumeration 

Source 

Name 

Definition 

Name 

Definition 

Value 

Label 

Minute_Within_Da 

y 

The  ordinal  index  of  a 

minute  within  the  day, 
starting  with  the  number  "0" 
at  midnight. 

EDCS 

Minute_Within_Ho 

ur 

The  ordinal  index  of  a 

minute  within  the  hour.  The 

index  starts  with  the 

number  "0"  at  the  beginning 

of  the  hour. 

EDCS 

Month 

The  Month  of  the  year  in  the 
Gregorian  calendar. 

1-12 

Periodic 

_Cycle_Time 

The  Time_Quantity  within  a 
within  a  cyclic  repeating 
phenomenon,  typically  the 
intervals  of  light  and  eclipse 
of  a  lighthouse. 

EDCS 

Periodic 

_End_Date 

The  end  of  the  active  period 
for  a  seasonal  object. 

EDCS 

Periodic 

_Restriction_  End 

The  Month  in  which 

restrictions  end  on  the  use 

of  an  object  due  to  climate 

or  other  limitations. 

1-12 

EDCS 

Periodi 

c_Restriction_Star 

t 

The  Month  in  which 

restrictions  begins  on  the 
use  of  an  object  due  to 

climate  or  other  limitations. 

1-12 

EDCS 

Periodic 

_Start_Date 

The  start  of  the  active 

period  for  a  seasonal  object. 

EDCS 

Permanent 

An  indication  that  an  object 
is  permanent  (as  opposed 
to  temporary). 

EDCS 

Time_Coordinate 

The  coordinate  value  for  a 

defined  temporal  reference 

frame. 

EDCS 

Time_Division_ 

Within_Day 

The  division  of  the  day  (one 
of  several)  marked  by  the 
passage  of  the  sun  through 
its  diurnal  cycle. 

1 

sunrise 

EDCS 

2 

daytime 

EDCS 

3 

sunset 

EDCS 

4 

night_time 

EDCS 

5 

continuous 

EDCS 

Time_Format 

The  format  of  a  time  of  the 
day. 

1-22 

EDCS 

Time_Of_Day 

A  time  of  the  day  formatted 
as  a  Time_Format. 

EDCS 

Time_Period 

A  period  of  time;  formatted 
as  specified  by 
Time_Period_Format. 

EDCS 
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Class 

Attribute 

Enumeration 

Source 

Name 

Definition 

Name 

Definition 

Value 

Label 

Time_Period_ 

Format 

The  format  of  a  period  of 
time. 

1 

iso 

EDCS 

2 

period_start_end 

EDCS 

3 

duration 

EDCS 

4 

period_start_ 

duration 

EDCS 

5 

period_duration_ 

end 

EDCS 

6 

reduced 

EDCS 

Time_Quantity 

A  quantity  of  time  (period). 

Season 

Season  of  the  year. 

1-4 

EDCS 

Year_Common_ 

Era 

The  Time.Quantity  as 
measured  by  the  Gregorian 
calendar  in  whole  years 
since  the  beginning  of  the 

Common  Era. 

USAGE 

Information  on 

the  usage  of 
certain  objects. 

EDCS 

Operating_Time 

The  times  during  which  the 
use  of  an  object  is 
unrestricted. 

EDCS 

Operating. 

Restrictions.Type 

The  conditions  during  which 
the  use  of  an  object  is 

restricted. 
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